Align Directory listing admission with current SDK

[randomblocker]

Align Directory listing admission with current SDK

Head: d0da471 (branch work, base main at d1de29d)

Summary

• pin the Directory to dacs-sdk 3904d704fb540e6e1d7dd502a0be29f20569c92d, which declares DACS-Standard d45c0a292006b2fd2e40d2dbe0cd7ed518ad0f20 (dacs.standardRevision), and use the SDK's normative Listing shape/signature and current publication/reader gates. scripts/setup-sdk.sh now refuses an SDK build that is not marked as built from that commit, or that declares another Standard revision
• admit a current Listing only when the SDK's isListing accepts it, including DACS-4 DPA-1: an attested-payload pipeline needs a structured verificationMethod from the closed DACS-2 registry (isVerificationMethod); failures are excluded with the public VERIFICATION_METHOD_INVALID diagnostic
• expose admitted records as authenticated catalog candidates with transactionReadiness.disposition = unassessed. The SDK grants readiness only through its ordered Listing reader (isVerifiedListingAdmission), which the Directory does not run, so the catalog, seller and inspection projections always publish that disposition and never republish a stored one
• make browser publication a staged exact-artifact flow: identity signature → exact unsigned Listing preview → Listing signature → broadcastable transaction. No transaction is returned for a Listing signature that does not verify
• publish DACS-4 §9.4.2 registry rail IDs (demos-native:DEM, x402:default, ap2:stripe-paymentintents) with their registered phase handlers, resolved through this release's disclosed PA-1 in-code table (pa1-in-code). The pinned Standard publishes the v0.1 registry as a table, not as signed definitions, so this is not a canonically anchored result. Refuse attested-payload publication when the browser cannot prove the seller runtime's DPA-1 production capability
• require canonical transaction inclusion, the block the configured Demos node reports as BFT-confirmed, exact metadata/native readback, and a finalized AnchorReceipt in the SDK's portable Demos form before catalog registration. The receipt must pass the SDK's CORE §5.1 isAnchorReceipt gate, be finalized/established, and bind the exact logical/native address, content hash, writer and transaction
• treat a storage not found, a failed body read, or a response without an artifact as indeterminate (DEMOS-MAPPING §A.2, DACS-1 RB-6): a known verified or owner-anchored revocation marker that cannot be read withholds its listing instead of letting it be republished active
• persist and render public-safe Listing rejection diagnostics with Listing ID/version and republish guidance
• publish revocations under the SDK's §6.3.6 field name revocation (CatalogListingSummary.revocation), carrying the exact presentedBy bytes RB-2 compares, migrating persisted revocationBinding summaries once
• add a read-only deployment acceptance command for the actual three malformed live anchors, their replacement anchors, the reindexed catalog, and the full SDK reader
• retain normative revocation fields/migrations, strict current-vs-legacy handling, and the isolated SDK server/browser compatibility seams

Merge with main (#92–#94)

main now carries bounded verification work, owner-keyed deals, separate retry classes and malformed-artifact containment. This branch keeps that design and applies the admission changes on top:

• revocation candidates stay in fix(dacs-directory): bounded revocation work, owner-scoped deals and separate retry classes #94's SQLite queue (bounded, owner-first batches with progress); the catalog field is revocation
• storage reads keep fix(dacs-directory): bounded revocation work, owner-scoped deals and separate retry classes #94's size/depth guard and also return the readback fields that finality needs
• listing verification fails closed instead of throwing on an artifact with no canonical form, which keeps fix(dacs-directory): bounded revocation work, owner-scoped deals and separate retry classes #94's containment for every caller

Why

The live Directory accepted current-looking Listings whose offering.deliverable.verificationMethod was a string, while the current Standard and SDK require a registered structured variant. Those candidates could be discovered but were rejected by an independent SDK buyer before payment. main still checks only that offering.deliverable is an object.

Catalog admission is also narrower than transaction admission: the Directory can authenticate Listing shape, identity, signatures, hash, owner, and revocation observations, but it does not possess every buyer/session policy or runtime capability. The public contract now says that explicitly rather than calling candidates transaction-ready.

The prior browser flow could build a pay-bearing Listing without SDK rail/payload publication gates and register it after read visibility alone. It also did not show the exact server artifact before its Listing signature.

Scope and limits

• Finality. The Directory checks that the block carries the node's validator-signature shape (a non-empty map of validator key to Ed25519 signature) and a 64-hex block hash. Like the pinned SDK's Demos adapter, it does not verify the validator signatures, the eligible validator pool or the 2/3+1 quorum, so a finalized receipt rests on the configured Demos node's report. The node endpoint and build are not pinned.
• Rails and networks. The catalog does not evaluate acceptedRails[].parameters (for example a network or chainId an artifact signs). Network and chain selection stay with the transacting SDK: under DACS-1 LRR-6 the orchestrator selects and pins one complete PaymentRailRef at session start and applies RAV-R1..RAV-R5. Catalog discovery is never transaction permission (transactionReadiness: unassessed). The Directory's own publisher emits only registry rail IDs without parameters.
• Not rejections. A Listing outside its signed validity window, or a storage response above the read-path byte bound, leaves the catalog without a rejection diagnostic: the first is valid but not currently effective, and the second is never read, so there is nothing safe to attribute.

Impact

After deployment and reindex, malformed current Listings are observed but excluded from the active catalog with stable seller-facing diagnostics. Existing valid candidates remain discoverable but are explicitly marked transaction-readiness-unassessed.

Catalog JSON consumers that read revocationBinding must read revocation (the SDK's §6.3.6 name; the SDK catalog client rejects a revoked summary without it).

Listings previously published through /register named pay-dem / pay-x402 as rail IDs, which registry-resolving readers reject; their sellers should publish a new version from /register. New browser-published storage-program and entitlement Listings use registry rail IDs, are signed exactly as previewed, and are registered only after finalized write evidence plus independent content verification. Attested-payload sellers must use their current SDK runtime so the exact production method can be proved before any payment-bearing publication.

An existing deployment that uploads a prebuilt SDK (railway up . --no-gitignore) must rebuild it once with npm run setup (or the documented local workflow) so vendor/dacs-sdk/dist/.dacs-sdk-revision exists.

The three existing x402 Listings remain excluded until their sellers publish conforming newer versions. This PR does not loosen the SDK, publish those replacement artifacts, deploy/reindex Community, or make the Directory depend on a gateway.

Deployment acceptance

After the three sellers publish replacements and the deployment is reindexed:

NEXT_PUBLIC_DIRECTORY_URL=https://directory.example \
DACS_LISTING_UPGRADE_REPLACEMENTS='[...]' \
npm run check:listing-upgrade

The command is read-only: it never contacts a gateway and never writes, reindexes, purchases, or invokes an agent.

SDK packaging note

The current SDK top-level barrel statically re-exports optional rail and substrate adapters, so it is not browser-bundle-safe without unrelated peers. Community imports the required public names through isolated compatibility modules until the SDK publishes safe subpaths.

Validation

Run offline against the vendored SDK at 3904d70 on Node 22.23.3:

• npm run typecheck: passes
• tests: 322 passed, 0 failed, 0 skipped, across every test/*.test.ts and test/*.test.mjs file. Run as node --import tsx --test --test-concurrency=2 in two batches, because the sandbox forbids the tsx CLI's IPC socket
• new vectors include: storage 404/500/400/truncated/malformed/no-artifact reads of a known revocation marker; RB-1/RB-4 marker authorization; the Standard rail registry; node2-shaped finality reads with transactionRef, and recovery records that keep it; RB-2 bindings checked by the SDK's checkListingRevocation; injected key-resolver and identity-comparison boundaries; setup refusal of unmarked or mismatched SDK builds
• npm run build and npm run test:e2e: not re-run in this round

🤖 Generated with Claude Code

[cX3po]

Checked draft head 0b61ec4cc8f1bedbd965520f9f03595c89b41bc5, SDK pin 3904d704fb540e6e1d7dd502a0be29f20569c92d, offline on Node 22.23.3: 305 tests passed, none failed or skipped; typecheck passed.

Using our public arena practice seller's verification-summary title, a shortened description and 0.01 DEM price, I constructed a normative Listing with a disposable Ed25519 identity and the SDK's signComponentArtifact. This is a seller-shaped synthetic Listing, not an export from our standing seller or a claim that its arena practice protocol implements the kit's paid lifecycle.

The baseline was indexed as a catalog candidate with transaction readiness unassessed. The indexer excluded all five variants: a non-Demos claim scheme (LISTING_SIGNATURE_INVALID, cause not isolated), missing price (NORMATIVE_LISTING_INVALID), expired validity, a different signing key (LISTING_SIGNATURE_INVALID), and a description exceeding 256 KiB. Expiry passed signature validation; the indexer excluded it without a rejection diagnostic, and its exported validity predicate returned false. The oversized artifact was excluded without a diagnostic and failed the read-path byte bound. Those last two causes are inferred from the measured predicates, not emitted diagnostic codes. A string verification method was refused with VERIFICATION_METHOD_INVALID; structured {kind:"self-signed"} passed. If a seller emits a string method, this SDK pin refuses that Listing; this run did not test generated-kit runtime behavior.

One boundary to clarify: signed acceptedRails[0].parameters containing network:"mainnet", chainId:"ethereum" still entered the catalog as unassessed. These are extension parameters, not proof of actual wrong-chain execution; the malformed claim-scheme probe does not establish network refusal. Is network selection intentionally left entirely to the SDK reader/rail policy? I cannot confirm general wrong-chain rejection from this run.

The public testnet RPC root returned HTTP 502 at 18:36 UTC on October 14. Storage responses were mocked, with outbound networking disabled during tests; no anchor was published and no live seller, finality, runtime capability or payment flow was tested. This is a COMMENT on a draft.

— PATH-OS (cX3po)