Fix gaps in recently merged Directory code found by a full sweep

[randomblocker]

Two full reviews of the DACS Directory code merged since 2026-10-08 (#87, #88, #92, #93, #94) found places where the Directory's verdicts differ from what the DACS Standard v0.4 requires, and rules no test pinned. This PR fixes them, adds a regression test for each fix, and adds rule tests for the rules a mutation run showed were unpinned.

Each fix's test fails when the fix is reverted. The typecheck is clean at every commit, and the whole suite passes at every commit (353 tests at the tip, up from 273 on main). Mutation testing over the nine modules these findings touch dropped the surviving mutants from 1,411 to 573. The remaining groups are listed at the end.

What changed, finding by finding

Revocation (DACS-1 RB-3, RB-5, RB-6)

• A listing whose revocation check is incomplete is no longer published as active. The check is incomplete while a candidate marker could not be read because of a transport failure, or is still waiting its turn. The catalog has no indeterminate status, so the listing is held back until a later pass completes the check.
• A revocation verified on an earlier pass stays revoked with its binding, even if its marker later cannot be read. It is carried forward only for the same listing version.
• Storage reads now tell a definite answer (404, 401, 403, 400, or content that cannot be an artifact) apart from a transport failure. A deleted candidate is rejected, so it cannot keep a listing held back forever.
• A rejected marker that is re-published in place with a corrected signature envelope is examined again. Candidates are now readmitted on a hash of the whole stored value.
• Tests: scan-fairness "a verified revocation stays revoked while its marker cannot be read or no longer verifies (RB-3)", "an unread or unexamined revocation candidate withholds the listing rather than publishing it active (RB-5)" and "a rejected marker re-published in place with a corrected signature envelope is examined again"; chain-storage "a storage read separates a definitive answer from a transport failure (RB-6)"; listing-rules "RB-3 retention carries forward only this listing version's own revoked record and binding".

Deal attribution without program names (DACS-5 §10.4.2)

• A discovered current-profile deal is attributed through the agreementRef its buyer bundle signs: the locator, the content hash, and a co-signed agreement whose buyer is the bundle owner. Program names are no longer used. Before, deals whose producers percent-encode the colons in program names (most deals on node2) were never attributed to their seller.
• Name-based resolution remains only on the labelled legacy SDK path.
• Test: scan-fairness "a discovered current-profile deal is attributed through the agreementRef its bundle signs, never a program name (§10.4.2)".

Canonical signature values (CORE SIG-6)

• Every current-profile signature value must be unpadded Base64URL with exact re-encoding. Hex, 0x hex, padded or standard Base64, whitespace and non-zero residual bits are rejected without trying other decoders. The legacy SDK profile keeps its own labelled reader.
• The register page now converts the wallet's hex signature to the canonical value before anchoring.
• SPEC_PIN records the Standard revision (v0.4, 4bb9e48), and the conformance vector files are vendored byte for byte.
• Tests: sig6 (the signature-value-encoding vectors, and seven non-canonical spellings on each verifier), signature-value-rules.

Per-jobId reconciliation (DACS-5 §10.5.1)

• A seller's verified deals now collapse to one authoritative copy per jobId: equal copies merge, a lone fully signed copy wins, and equal standing voids the jobId, whoever the buyers are. fix(dacs-directory): bounded revocation work, owner-scoped deals and separate retry classes #94 keyed this on (buyer, jobId).
• Tests: verification "verified reputation deals collapse to one authoritative copy per jobId, whoever the buyers are (§10.5.1, BB-6)"; scan-fairness "two buyers' attributed deals with the same jobId both reach the seller's record".

Listing validation (DACS-1 §6.3.4, LR-2, DACS-3 PS-3, DACS-4)

• A listing is published only once validity.notBefore has passed.
• The 16 KB LR-2 cap is measured on the canonical form without the signature, not on the raw JSON.
• The negotiate-sealed-envelope-procurement phase is added, and the full PS-3 pricing table is applied.
• An auction's selectionRule must come from the DACS-4 enum or be a content-hash-bound rule ref.
• revokedAt is bounded by magnitude only, as CORE requires.
• Recognised listing members must have their defined types. That covers the deliverable (all four kinds), BundleRequirement, terms, rails, capabilities and the parameters of each phase kind, including the sealed-envelope rule that its selectionRule must equal the pricing's.
• Tests: listing-verification "the indexer publishes a current listing only once validity.notBefore has passed", "PS-3: each negotiation pattern accepts exactly the pricing kinds DACS-3 allows", "auction pricing accepts only the DACS-4 selectionRule enum and content-hash-bound rule refs", "LR-2 caps the canonical form at 16,384 bytes, signature omitted, not the raw JSON" and "schema conformance: recognised listing members must have their DACS-1/3/4 types"; verification "standalone revocation verifier bounds a signed revokedAt to the CORE numeric profile, not to non-negative integers".

Agreement and vet records in the evidence graph (DACS-3 §8.5.2, DACS-2 §7.5 and §7.7)

• An agreement must conform to the pinned listing: currency, price (fixed, band, fixed-price fallback, metered), rail, deliverable, pattern, role direction and commitment artifact.
• VerifyResult and composite records must carry their required members. A VerifyResultRef's recipeVersion must match the result it points to. A composite must be bound to a session party's bundle and to the listing's requirement, and a successful vet phase or a committed session must rest on a passing record.
• Graph artifacts are accepted up to the 128 KB DACS-5 storage soft cap. The previous 64 KiB limit rejected valid bundles.
• Tests: current-indexer "DACS-3 §8.5.2: an agreement conforms to its listing in currency, price, rail, deliverable, pattern and role direction", "the evidence graph rejects an agreement that does not conform to its listing", "current evidence graph resolves VerifyResult authority attestations", "a vet record binds the listing's requirement and must pass for a vet phase or agreement to rest on it (DACS-2 §7.7, VPC-4)" and "a bundle within the 128 KB DACS-5 storage soft cap verifies, and one above it does not".

Browser and API decisions

• The in-browser deal verdict moves unchanged into browserDealVerdict and is tested input by input.
• The artifact proxy's locator guard is tested: no ref other than a native storage locator reaches the node.
• The deal page shows a delivery attestation only when the record's storage owner is the expected seller, and no longer says it is signed before the check runs.
• Tests: verification "the browser deal verdict is strict only with matching parties, signatures, refs and a registered copy role"; artifact-route; deal-page.

Smaller fixes

• SB-2 ties now break on the lower evidence hash (current-indexer "SB-2: a settlement id cited at the same time by two jobs counts for the lower evidence hash").
• The node's 400 INVALID_REQUEST is terminal (scan-addresses "storage failures are classified into public-safe operational causes").
• The storage-limit comments are corrected, and the README now documents ARTIFACT_REJECTED, the pinned upstreams and the node's storage-read contract, and states the binding ceiling as it is. The notes calling the SDK repository private are removed, and the stale import comments are corrected.

Rule tests from the mutation run

• New files: listing-rules, revocation-vectors, evidence-graph-rules, bundle-binding-rules, indexer-binding-rules, legacy-deal-rules, identity-rules, reputation-rules and signature-value-rules.
• Each case mutates one field of a validly signed fixture and signs it again, so only the rule under test can reject it.
• The legacy SDK deal path gets its first positive end-to-end test.

Wire and behaviour changes

There are no external users yet, but these are visible:

• Listings, revocation markers and current-profile artifacts with a hex or padded signature value no longer verify. Republish them with the canonical value; their content hash is unchanged.
• A listing whose revocation check is incomplete is held back from the catalog until a pass completes the check.
• Listings that fail the schema or PS-3 rules, or whose notBefore is in the future, are no longer published.
• Two buyers' fully signed, divergent deals for one seller and jobId now void that jobId.
• DealRecord gains fullSignatureStanding, each settlementTxIds entry gains evidenceHash, and discovered deals gain agreementLocator.
• New exports: readAnchorResult (chain), hasPendingRevocationCandidates (store), browserDealVerdict (bundlePolicy), agreementListingConformance and normalizedHash (evidenceGraph), and the signatureValue module.
• The content_hash of revocation_candidates now hashes the whole stored value, so existing rejected candidates are examined once more.

Not in this PR

• Bounded work. There is no total across signers on stored bindings, which are re-verified every pass (reindexCore.ts:143-146, bundleBinding.ts:108-127). The revocation-candidate queue has no cap (store.ts:127, 257-271; scan.ts:186-189, 552). Because an incomplete check now holds a listing back, a flood of junk candidates can delay its publication.
• §8.5.2 checks 5 and 6, and CA-7. These need the CommitmentRecord, which a bundle does not reference and which is addressed only by name.
• Fractional revokedAt. The pinned SDK canonicaliser rejects every fraction.
• Build pins. The CI actions are pinned by tag rather than by SHA, and the packaged-SDK fast path in scripts/setup-sdk.sh does not check the SDK revision.
• The legacy SDK deal path. It is reached only when neither bundle copy carries bundleVersion: "1", but the pinned SDK writes "1", so its deals take the current path and fail there.
• Remaining mutation groups. These are listed in the fix report with exact locations.

🤖 Generated with Claude Code