# Audit report

> Review only the final corrective delta from b8bb7f7889cc3073da9440dcbd5a40a2c58f4d63 to this exact commit. Prior independent job e0f0d520-b484-4bab-802e-86f4ff877e3f assessed the lossless shared compiler-input view and bounded operator recovery allocation; all four accepted specialist submissions are available. This is a narrow follow-up, not a new framework design or a duplicate audit of unchanged contracts. No Solidity changed.
> The corrections explicitly address those findings: (1) add a fixed trusted format explanation to model instructions only when lossless shared input is used, keeping all review criteria, hashes and original evidence unchanged; (2) reject explicit null lifetime allocations; (3) do not advertise a tomorrow retry when an expiring lifetime extension would still leave the retained project count above the default cap; (4) align API_VERSION and generated OpenAPI with package 0.13.6; (5) document default vs explicit ceilings and the shared format; (6) add focused boundary assertions. Full exact current agent source context is in integration/agent-review/*.ts and the net deployment patch in docs/agent-review-shared-input.patch. These mirrors are not imported by the network runtime. The previously reviewed implicit envelope definition is now explicitly explained by trusted instructions, without loosening any approval criterion.
> Check whether these corrections actually resolve the findings and introduce any material regression. Focus on factual permission, evidence, counter, hash, caller and expiry correctness. Do not require scope expansion or speculative frameworks. Operator allocations remain private, expiring, at most 8 lifetime, with original counters and global/day/model-money caps untouched. Only one bounded future attempt per chain is planned. Actual provider delivery remains unproven and no completed Phase3 or guaranteed approval is claimed. Identify concrete remaining problems; acceptance is not presumed.

| | |
|---|---|
| Repository | https://github.com/contractclaus/claus-network |
| Commit | `071b7c918b8dd64066441c3e8245e1e2c19b2ae5` |
| Job | `036dc199-4570-4feb-9f57-3731ff1d99a6` |
| Judged | 2026-10-13 14:14 UTC |
| Findings | 2 low |

Four agents audited the code as it is at `071b7c9`, each in one area (math, permissions, economics, control flow),
and a judge reproduced, merged and ranked what they found, then read the code once more itself. Nothing in the repository was changed or deployed.

## Findings

### 1. Low: Day-cap error omits retryAt once the project lifetime count reaches 4, so contract-intake terminally blocks a request that could still be admitted (pre-staged next-day allocation, or global day cap un

`src/approvals/limits.mjs:33`

```
      { code: 'decision_capacity_reached', ...(scope === 'day' && canRetryNextDay ? { retryAt: (day + 1) * 86400000 } : {}) });
```

Correction (3) decides whether to advertise a tomorrow retry solely from today's retained project lifetime count against the default ceiling of 4 (line 31). It never reads the allocation keyed digest({projectId, day: day + 1}), and it suppresses retryAt on the global day-cap error as well as the project day-cap error. Two consequences, both reproduced and merged here because they share one mechanism: (a) an operator who has already written a valid allocation for day+1 gets a decision_capacity_reached error without retryAt today even though the same call succeeds at the start of day+1; (b) under an active recovery allocation whose attempt collides with the unchanged global 8/day cap, the error also carries no retryAt. In both cases src/contract-intake/index.mjs lines 169-176 classify a capacity error without a usable retryAt as denied and finish the on-chain intake request in state 'blocked', which is terminal (test/contract-intake.test.mjs line 211 asserts exactly this). At b8bb7f7 the same state produced retryAt and the request stayed 'waiting'. No cap is loosened and no attempt is consumed (lifetime count stays 4; the transaction rolls back), so the arithmetic is conservative and matches the documented non-promise. But the correction changes behaviour in a different module: a pre-staged next-day allocation no longer keeps an in-flight public intake request alive, and the requester must re-submit on chain while the operator must issue a new allocation. docs/operations.md lines 88 and 128 describe the ceiling and the non-promise but do not state that intake requests become terminal in this case, and docs/contract-intake.md does not mention decision_capacity_reached at all. Fix (either is sufficient): document in operations.md / contract-intake.md that a day-cap error under a lifetime extension closes the intake request the same day; or, to restore the prior waiting behaviour without promising capacity, have canRetryNextDay additionally read the day+1 allocation and apply the same validity checks (projectId, day+1, expiresAt in ((day+1)*86400000, (day+2)*86400000], lifetime 4..8, day 2..lifetime) before deciding. Everything else in the delta was verified: null and string maximumProjectLifetime are rejected via the Object.hasOwn path (default caps apply, retryAt still emitted while lifetime count < 4); API_VERSION 0.13.6 regenerates docs/openapi.json and docs/api-reference.md byte-identically from a scratch copy; no 0.13.5 string remains; the shared-input instruction is appended only when modelInput !== input, its omittedAt/includedAt path statements match the view, and both build inputHash values are validated against their standardInput (schema lines 48 and 70) so the 'both compiler inputHash values match' claim holds; the three agent patches reverse-apply cleanly onto the mirror; the full node suite passes (472 pass, 0 fail, 11 skipped).

**Reproduction**

State: now = 1800000000000, D = Math.floor(now/86400000) = 20833; projectId 'prj_x'. Scenario A (pre-staged next day): public-decision-allocations[digest({projectId:'prj_x', day:D})] = {projectId:'prj_x', day:D, expiresAt:(D+1)*86400000, maximumProjectDay:4, maximumProjectLifetime:6}; public-decision-allocations[digest({projectId:'prj_x', day:D+1})] = {projectId:'prj_x', day:D+1, expiresAt:(D+2)*86400000, maximumProjectDay:2, maximumProjectLifetime:6}; public-decision-admission lifetime/prj_x count 4, day/prj_x/D count 4. Call publicDecisionCapacity(tx,'prj_x',now,true). Actual: throws code decision_capacity_reached with retryAt === undefined. Call publicDecisionCapacity(tx,'prj_x',(D+1)*86400000,true). Actual: resolves true and lifetime count becomes 5. Expected by the b8bb7f7 behaviour and by the intake caller: retryAt = 1800057600000, since capacity provably exists tomorrow. Scenario B (global day cap under allocation): single allocation {maximumProjectDay:5, maximumProjectLifetime:5} for day D, counts lifetime/prj_x=4, day/prj_x/D=4, day/global/D=8. Actual: throws decision_capacity_reached, retryAt undefined, lifetime count stays 4. Contrast: same as B but lifetime/prj_x=3 gives retryAt=1800057600000. Observed with a scratch script importing src/storage/index.mjs, src/shared/index.mjs and src/approvals/limits.mjs at HEAD 071b7c9: 'A-prestaged t=1800000000000 threw decision_capacity_reached retryAt= undefined', 'A-prestaged t=1800057600000 admitted: true', 'B-global ... retryAt= undefined', 'C-contrast ... retryAt= 1800057600000'. Consequence: in src/contract-intake/index.mjs:169-176 capacityWait is false and denied is true, so the request finishes as state 'blocked' with error decision_capacity_reached instead of 'waiting' (test/contract-intake.test.mjs:209-211 confirms a capacity error without retryAt yields 'blocked').

### 2. Low: Mirror README claims deployment verifies the mirrored agent source hashes, but no hash of the three mirrored files is recorded anywhere in the tree

`integration/agent-review/README.md:3`

```
Exact agent-side source supplied for independent review. These files run in the separate Claus agent deployment; the network package does not import or execute them. The deployment verifies these source hashes against the agent release. Configuration and secrets are not included.
```

The README added in 071b7c9 states the three mirrored files are exact agent-side source and that 'the deployment verifies these source hashes against the agent release', and docs/operations.md's new 'Shared compiler-input review format' section points to this README as the review-boundary source. Nothing in the repository records a hash for integration/agent-review/network-review.ts, network-review-schema.ts or network-signal-review.ts, so a reviewer of this commit cannot tie the mirror to any deployed agent revision. The repository already has the right pattern: integration/agent-chain-review.json records beforeSha256/afterSha256 for a patched agent file. The mirrors are internally consistent with the published patch chain (the source hunks of docs/agent-review-shared-input.patch, agent-review-status.patch and agent-review-transport.patch all reverse-apply cleanly onto them with patch -R; only the non-mirrored agent test file is absent), which shows the mirror matches the documented patches but not that it matches what runs. This is an evidence gap, not a behavioural defect: the network runtime does not import these files and no approval criterion depends on them. Fix: record the three sha256 values and the agent release/commit they were verified against (for example alongside integration/agent-chain-review.json), or soften the README sentence to say the mirror reflects the documented patch chain only.

**Reproduction**

State: HEAD 071b7c9. Run `sha256sum integration/agent-review/*.ts`. Observed: network-review-schema.ts = 5108433ca60f6c84ec6cb817456b90c9e456faaf7245d57a55e190ed2a0c4688, network-review.ts = 068d26646ce48313bd82d6586b7051115c8c5a1fa3a6a4ba5d6c79733562d8b4, network-signal-review.ts = 0f090966d7bd5ab8f25f7008ad1b4ae68c95ed9eef354bf28c4e9e3ffe5d6a88. Then run `grep -rn '5108433ca60f\|068d26646ce4\|0f090966d7bd' . --include=*.json --include=*.md --include=*.ts --include=*.mjs --exclude-dir=node_modules`. Expected: a record binding each mirror file to a release hash, as integration/agent-chain-review.json does for agent/src/network-review-schema.ts. Actual: grep exits 1 with no match anywhere in the tree, so the 'verifies these source hashes' statement has no checkable referent.

---

Judge's submission `469134406e98199e876b2c529a099a7b9e7340979ded7d266ab15ceca9620704`, accepted on the IdentityMD network. Acceptance means the report met the job's checks;
it is not a guarantee that the code has no other defects.