fix(plugin-auth): a refused auth setting no longer drops the settings saved with it

[objectstack-fleet]

Fixes #20412

Clause-②: no

What changed

AuthPlugin's auth settings pass (bindAuthSettings → applySettings, packages/plugins/plugin-auth/src/auth-plugin.ts) used to send the whole namespace to AuthManager.applyConfigPatch() as ONE patch inside one outer try. When the manager refused one key, the whole patch was dropped (password policy, MFA, rate limits, session lifetime, social providers) and the only trace was ctx.logger.warn('Auth: failed to apply auth settings: …'), while the settings console showed every value as saved.

Seat ruling applied: a refused key does not take its accepted siblings with it.

• The pass is now applied in pieces, split along the lines where the manager can refuse. applyConfigPatch validates a patch on entry wherever it carries emailAndPassword (assertAudienceConfig, against the standing audience posture) or plugins (assertScimAdminCoherence). Each settings key that lands in one of those blocks is applied ALONE. Every other key goes out in ONE application that the manager does not validate.
• mfa_required: true stays one piece with the twoFactor plugin it turns on. A refused plugins block therefore leaves MFA at its standing value too, and MFA is never enforced without its enrollment endpoints.
• Every piece has its own try. A refusal is logged ONCE at error, naming the key, saying what keeps ruling and what the console shows, followed by the manager's own message, which carries the remedy. This follows the audience block beside it: [auth] auth settings REFUSED (auth.require_email_verification) — the standing runtime value keeps ruling while the settings console shows the stored value as saved; the other auth settings in this pass still apply. [audience] invalid audience configuration: posture 'open' FORCES email verification on unless the DEPLOYMENT turns it off — …
• The outer catch is left with only a pass that fails as a whole, the namespace read first among them. It moves from warn to error ([auth] auth settings NOT APPLIED — …) for the same reason: stored values the console shows as saved were not applied. This is the same line the card names as the defect.
• The plugin decides nothing. The manager's verdict on each piece is the verdict, and no validation is duplicated in the plugin. The audience block, its order (after the pieces, so it is judged against the verification state this pass just applied) and its messages are unchanged.

Premise check (the ruling's precondition), measured before writing the fix

The refusal can be attributed without re-implementing validation. applyConfigPatch (auth-manager.ts, around line 4162 at 40b315b0) runs exactly two entry validators, each gated by which top-level block the patch carries. Splitting the pass along that gating gives each refusable key its own verdict from the manager. It needs no knowledge of what the validators check. Per-key isolation yields the same accept/refuse verdict as the whole-block application for every key on this tree: assertAudienceConfig reads only requireEmailVerification from emailAndPassword, and assertScimAdminCoherence reads only admin/scim, which this pass never sets. So nothing that used to be accepted is refused, and the refused key is refused for the same reason. Landing point: the plugin (the consumer that composed the one patch), not auth-manager.ts.

Live triggers, measured on main 40b315b0 before the fix (new pins run against unmodified auth-plugin.ts)

src/auth-settings-refusal-isolation.test.ts drives the real AuthPlugin + AuthManager through a stub settings namespace read:

trigger	on 40b315b0
console door, no stack config: posture opened through the console, then require_email_verification: false saved with siblings	session.expiresIn stays undefined (every sibling dropped)
stack-config open + console-stored false at boot	session.expiresIn undefined
stack-config email_domain + env (OS_AUTH_REQUIRE_EMAIL_VERIFICATION) false	session.expiresIn undefined
plugins SCIM/admin coherence refusal (OS_SCIM_ENABLED appearing after construction with plugins.admin: false)	session.expiresIn undefined
failed namespace read	logged at warn only
CONTROL: clean pass	green

Result: Tests 5 failed | 1 passed (6), with every negative pin failing on expected undefined to be 259200 / 604800 or on the missing error line.

The settings service has no cross-field validation between require_email_verification and audience_posture (packages/services/service-settings/src/manifests/auth.manifest.ts). The first trigger is therefore reachable by two console saves, with no stack config or env involved.

Surface beyond the claim's file list (declared)

• scripts/check-durability-degradation-log-level.mjs: applyConfigPatch joins DURABILITY_CRITICAL_CALLEES (AGENTS.md, Degradation log levels: "found a new one, add it to DURABILITY_CRITICAL_CALLEES in the same PR that fixes it"). Seams 36 → 38, all loud. With auth-plugin.ts at 40b315b0, the gate reds on the old warn catch (ablation below).
• scripts/measure-durability-swallow-family.mjs: that census's by-value gate-vocabulary copy gains the same name. check:swallow-census-controls reds on the drift otherwise, measured: "declared by the gate, missing from the copy: applyConfigPatch".
• scripts/engine-double-contract.pinned.json: node scripts/check-engine-double-contract.mjs --write for the new test file's findOne double. The double is copied from audience-posture-setting.test.ts, which is already pinned. The gate itself asked for this: "New pinned coverage is GOOD … Run --write and commit". The result was one added row and 0 seam rows lost.

No packages/spec, no service-settings, no auth-manager.ts change.

Tests

• New packages/plugins/plugin-auth/src/auth-settings-refusal-isolation.test.ts (6 tests):
  1. with a live refusing key in the pass, siblings from every family ARE applied: password_min_length (same emailAndPassword block), password_require_complexity, mfa_required + twoFactor, rate_limit_max, session_expiry_days, Google social provider;
  2. the refusal is ONE error line naming the key and carrying the manager's remedy text, and the old warn never fires;
  3. CONTROL: a clean pass applies everything and reports no refusal;
  4. the plugins-block refusal names each key it carried (password_reject_breached, mfa_required) and keeps MFA with its plugin;
  5. a failed namespace read is one error line (auth settings NOT APPLIED).
• pnpm --filter @objectstack/plugin-auth exec vitest run --maxWorkers=2: Test Files 115 passed (115), Tests 2460 passed (2460) (at 846b2858; later commits touch only scripts/ ledgers and the census copy).
• pnpm --filter @objectstack/plugin-auth run typecheck (after pnpm --filter @objectstack/plugin-auth build): exit 0. The new test file is in the tsconfig.test.json program (--listFiles: 1 hit), and check:test-typecheck: OK.
• pnpm exec eslint --no-inline-config --format json on the four changed lintable files: 4 files, 0 errors, 0 warnings. The population is read from eslint.config.mjs (files: ['**/*.{ts,tsx,mts,cts,js,jsx,mjs,cjs}'] minus NEVER_LINTED; none of the four reported as ignored). Invariance: type-aware linting is not enabled anywhere in eslint.config.mjs (no parserOptions.project, no projectService), so this diff cannot move any untouched file's verdict. The repository-wide pnpm lint is CI's.

Ablations (the fix committed first; each leg's restore proven by blob hash plus an empty git diff HEAD)

1. The old whole-pass drop put back. auth-plugin.ts was restored to 40b315b0 (tree only). Proven on disk: the blob equals the base blob dd862c8d, the old warn count is 1 and the applyPiece count is 0. The new pins went red, Tests 5 failed | 1 passed (6) (four on expected undefined to be 259200 / 604800, one on the missing error line; the control stayed green). check:durability-log-level went red: ✗ 1 durability report(s) degrade quietly … packages/plugins/plugin-auth/src/auth-plugin.ts:1799. Restored to the HEAD blob 45e547d5.
2. Isolation kept, refusal logged at warn (node scripts/ablation-replace.mjs, anchor hit 1 → 0, blob 45e547d5 → 0a104f02). The pins went red, Tests 4 failed | 2 passed (6): each fails at expected [] to have a length of 1 (2 for the plugins test). The siblings still applied, so this leg isolates the level pin. check:durability-log-level went red at auth-plugin.ts:1767. Restored to 45e547d5 with git diff HEAD empty.

Gates (derived by node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --commands at the final head, 86 commands, all run at 950c40c5)

• 84 exit 0, including check:durability-log-level, check:swallow-census-controls, check:engine-double-contract, check:logger-receiver-detach, check:doc-authoring, check:nul-bytes, check:issue-citations, check:adr-0087-registration --base origin/main, check:changeset-no-major and check:pm-dispatch-gates (its battery took 1026.8s on this shared box).
• NOT MEASURED: check:dual-build-cjs-loads. Reason: PREREQUISITE NOT MET (exit 3), because the gate reads the built output of every workspace package and 39 have no dist/ in this worktree. A targeted probe: plugin-auth's own dist/index.js (CJS require) and dist/index.mjs (ESM import) both load, and AuthPlugin is a function.
• NOT MEASURED: check:type-check-debt. Reason: PREREQUISITE NOT MET (exit 3), because the ledgered packages runtime, service-cluster and service-job have no built type entry. This diff touches none of them. plugin-auth's own typecheck and check:test-typecheck are green above.
• Also run, because the diff edits their inputs: check:optional-error-sink, check:startup-registry-verdict, node scripts/measure-return-propagating-durability-seams.mjs, node scripts/measure-durability-swallow-family.mjs --self-test (all families), and packages/metadata-protocol sys-metadata-repository.draft-drain.test.ts, which reads the gate file (11/11). All exit 0.

Acceptance notes

• Order inside one save (observation, pre-existing, not changed here). The verification piece is still judged against the standing posture before the same pass's audience declaration is applied. The audience block's comment records this order as deliberate. Take one save that both closes the posture (open → invite_only) and stores require_email_verification: false. That save logs one REFUSED line for the key. The effective requirement already matches (under invite_only an undeclared value resolves to off), and the next pass accepts the stored false. Before this change the same save dropped the whole pass at warn. No one else is carrying this: noted, not filed.
• Reach of the plugins refusal. It is reachable from this pass only when OS_SCIM_ENABLED appears after AuthManager was constructed with plugins.admin: false. The constructor refuses an incoherent config at boot, and buildPluginList() separately refuses the lazy better-auth build in that state. The pin holds the MFA/twoFactor coupling and the per-key naming, and it is not a claim of common reach.
• A refused value that stays stored is re-reported on every later pass (each settings change re-runs the pass), the same cadence as the audience block's REFUSED line.
• Log text change for operators, stated in the changeset: Auth: failed to apply auth settings: is gone. It is replaced by [auth] auth settings REFUSED and [auth] auth settings NOT APPLIED.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/plugin-auth, touching 13 documentable anchor(s).

2 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/deployment/self-hosting.mdx (via emailAndPassword (literal, a string literal in bindAuthSettings))
• content/docs/permissions/authentication.mdx (via mfa_required (literal, a string literal in bindAuthSettings), password_reject_breached (literal, a string literal in bindAuthSettings))

What this run could not see

• the SDK route bridge reached 54 of 206 client-bound route-ledger rows — the other 152 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 152: 0 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 55 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 97 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.
• a key NAME is not a key, so the hand re-read the line above prescribes can land on the wrong schema. The same spelling is authorable on one governed type and a [REMOVED] tombstone on another for each of active, aria, joins, objects, template, tools and version (censused on [finding] tools is a key on BOTH AgentSchema (tombstoned, dead) and SkillSchema (live, cloud-attested), so a name-based search attributes skill examples to the agent key — it produced a false stop-the-line alarm on PR #19059 #19093 over the liveness ledger's governed types, top-level keys); nothing in a search result distinguishes the two, so a grep hit on a LIVE example reads as evidence about the DEAD key. Measured on fix(spec): the agent.tools liveness row says dead — it claimed live on a key the schema tombstoned #19059: content/docs/ai/agents.mdx was reported as contradicting the agent.tools tombstone over its tools: example at :161, which is inside the defineSkill({ block opened at :155 — the page was already correct. Settle ownership by PARSING the value against both schemas, never by the name: that literal PASSES SkillSchema, and as an AgentSchema it FAILS at tools with the tombstone prescription. ⛔ These names are not the whole class — a key retired through a .strict() guidance map leaves no tombstone in the walked shape and none of them here (tool.category, live as AIToolDefinition.category).

Coarse fallback — 15 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 24b7085939ddee31fbeb59c049b0576cf51acf37 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 90165465b613a4a980ac920cc7d735b80d11b108 — the merge of head 950c40c51df7bcc81c9988a3e9ccd957140b6c65 into base 24b7085939ddee31fbeb59c049b0576cf51acf37, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin 90165465b613a4a980ac920cc7d735b80d11b108 && git checkout 90165465b613a4a980ac920cc7d735b80d11b108
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 24b7085939ddee31fbeb59c049b0576cf51acf37 950c40c51df7bcc81c9988a3e9ccd957140b6c65 && git checkout -B drift-repro 24b7085939ddee31fbeb59c049b0576cf51acf37 && git merge --no-ff 950c40c51df7bcc81c9988a3e9ccd957140b6c65

node scripts/docs-audit/affected-docs.mjs --json 24b7085939ddee31fbeb59c049b0576cf51acf37

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs 24b7085939ddee31fbeb59c049b0576cf51acf37 → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[objectstack-fleet]

Contract review

Served-tier: CONTRACT_REVIEW_TIER
Head-sha: 950c40c51df7bcc81c9988a3e9ccd957140b6c65
Local-runs: none

Inputs read: card #20412 (body + all 3 comments: claim 5867200492, os-dev-report 5868596370, seat ACCEPT 5868627018), PR #20429 body, its 6-file list, the net diff against main 24b70859 (base of the PR = origin/main at reading), the check-runs on the head (three polls, last at 2026-09-28T11:13:45Z), and file content at the head and at origin/main via git show / git grep on a fetched review ref (no checkout). auth-manager.ts is byte-identical at the head and at main, so every judgment below about the manager reads the unchanged validator.

① Derived judgments

The security question first — does any split change WHICH values the manager accepts or refuses, and can any piece now land a combination the whole-patch validation refused as incoherent. Read off applyConfigPatch (auth-manager.ts 4162-4239, unchanged): it shallow-merges emailAndPassword and plugins into the standing config, replaces audience and socialProviders whole, then runs exactly two entry validators, each gated on which top-level block the PATCH carries — assertAudienceConfig(next.audience, next.emailAndPassword, declarant) when the patch carries audience or emailAndPassword, and assertScimAdminCoherence(next.plugins) when it carries plugins. Nothing else in it throws.

1. The unvalidated patch piece cannot be refused — RIGHT. At the head, patch never receives emailAndPassword (every field goes through emailAndPasswordField into refusable), never plugins (password_reject_breached and mfa_required: true are refusable pieces; mfa_required: false sets only patch.mfaRequired), never audience (separate block, unchanged). So neither validator runs on it, exactly as the PR claims. Its applyPiece catch is a defensive dead branch; its key list names every explicit key not in a piece, including keys that contributed nothing (a malformed password_min_length, an invalid membership_policy) — cosmetic and unreachable, not wrong.
2. The four emailAndPassword pieces that do not carry requireEmailVerification (email_password_enabled, signup_enabled, password_min_length, password_max_length) are always accepted — RIGHT, and no narrowing. assertAudienceConfig reads from emailAndPassword only requireEmailVerification (audience-posture.ts 295-312). The declarant is recomputed from options.requireEmailVerificationFrom ONLY when the patch's emailAndPassword carries requireEmailVerification (auth-manager.ts 4213-4218); otherwise the standing deploymentDeclaredVerificationOff is kept. So a piece applied with options undefined is judged as (standing audience, standing rEV, standing declarant) — the standing state, which is self-consistent by construction (the constructor validates the deployment declaration at 1391-1392; every accepted patch validated its merged result). My initial concern — that a piece without the from option would be judged as console and refuse a previously accepted key when the deployment had turned verification off under open — does not hold on this code: the standing flag rules for such a piece.
3. The require_email_verification piece gets the same verdict the whole patch got — RIGHT. Same standing audience (the audience block still runs after the pieces), same value, same from derivation (sources.require_email_verification === 'env' ? 'deployment' : 'console', moved verbatim from the old whole-patch call), same merged rEV. The three refusals — false under email_domain from any source, a console false under open, and the merged-audience refusal when a pass OPENS beside a console false — are unchanged. A deployment false under open (env source, or a stack-config false with a later console false agreeing with it) is still accepted.
4. The two plugins pieces get the whole block's verdict — RIGHT. assertScimAdminCoherence reads only admin and scim from the merged block (auth-manager.ts 398-411, resolveScimEnabled = scim ?? OS_SCIM_ENABLED ?? false); neither { passwordRejectBreached } nor { twoFactor: true } carries them, so each piece is judged on the standing admin/scim plus env, as the whole block was. Keeping mfaRequired: true in the same piece as twoFactor: true is RIGHT: a refused plugins block leaves MFA standing, so MFA is never enforced without its enrollment endpoints (test 4 pins mfaRequired and twoFactor both undefined after the refusal).
5. No piece can land a combination the whole-patch validation refused as incoherent — RIGHT. The whole patch was refused in exactly three cases (rEV false under email_domain; console rEV false under open; standing admin: false with effective SCIM). In each, the refusal is attributable to one key's own verdict, because the validators read no other key from this pass — not enabled, disableSignUp, minPasswordLength, maxPasswordLength, mfaRequired, session, rateLimit, socialProviders, passwordRequireComplexity, membershipPolicy, nor any of the session/lockout/IP keys. There is no cross-key invariant on this tree under which "rEV refused, siblings applied" is an incoherent state the old validation protected against; the old drop was collateral, which is the card's defect. The PR's premise ("per-key verdicts equal whole-block verdicts") is measured correctly. Conversely nothing previously accepted is now refused (items 2-4). The accept-set of the manager is unchanged in both directions.
6. Sequential pieces accumulate — RIGHT. The manager's shallow merge of emailAndPassword and plugins means a later piece does not wipe an earlier one; the CONTROL pin holds requireEmailVerification: true and minPasswordLength: 12 together after two emailAndPassword pieces. Coverage note, not a defect: two ACCEPTED plugins pieces both surviving (passwordRejectBreached plus twoFactor) is not pinned by the new file — correct by the manager's merge, and nothing in the diff can break it.
7. No torn intermediate state — RIGHT. After the single await settings.getNamespace('auth'), the mapping, every applyPiece, and the audience block are synchronous; this.config is never observed mid-pass, and the instance invalidation (this.auth = null) fires on the first piece and no-ops on the rest. Order relative to the audience block (pieces first, audience judged against the rEV state this pass applied) is preserved.
8. Log levels — RIGHT. The per-piece refusal is error with consequence (standing value rules, console shows stored) and remedy (the manager's own message) in one line, logged once per refused piece; the outer catch moves to error (NOT APPLIED) with consequence and fix. Both match AGENTS.md's durability/consistency question (persisted and runtime state disagree while nothing looks broken). The leg-1 ablation shows the durability gate also judges the outer catch, since it guards the audience block's applyConfigPatch, so error there is required by the widened vocabulary, not optional. No tracker number in any runtime string.
9. Public surface — RIGHT: none moved. No export, option, schema key, error code or route changes; AuthPlugin and AuthManager signatures untouched. The operator-visible change is the retired warn line Auth: failed to apply auth settings: replaced by two error lines; the changeset states it with the alert-matching migration. At the head, no doc names the old line (git grep: only the changeset and two tests asserting its absence); ADR-0069 names bindAuthSettings → applyConfigPatch as the channel and says nothing about the pass being atomic, so no doc is falsified. The Docs Drift advisory's two pages match on literals (emailAndPassword, mfa_required, password_reject_breached) whose meaning this diff does not change.
10. Gate vocabulary widening — RIGHT. applyConfigPatch joins DURABILITY_CRITICAL_CALLEES and the census's by-value copy, as AGENTS.md prescribes for a seam found and fixed in the same PR. Non-test call sites at the head are the two in auth-plugin.ts (both now at error) and the definition; the four packages/qa/dogfood/test callers sit outside any catch. One findOne ledger row for the new test, written by the gate's own --write — RIGHT.
11. Residual, not wrong (the PR's Acceptance note). One save that closes open → invite_only AND stores a console require_email_verification: false logs one REFUSED line for that key (judged against the standing open) and the false lands on the next pass. Before this PR the same save dropped the posture change too, because the throw escaped to the outer catch before the audience block ran; the head is strictly better and the residual is loud and names the remedy.

② Semver level

@objectstack/plugin-auth (published, private unset, 17.4.0 at main) takes a patch changeset; no skip-changeset label on the PR; Check Changeset green. RIGHT: runtime behaviour of a released package moves (accepted siblings now apply; a log line changes text and level) while nothing authorable, exported or on the wire changes — item 9. The PR body and the changeset body each carry the line Clause-②: no at line start, with no (widening)/(narrowing) arm — RIGHT, by items 2-5 the accept-set is unchanged in both directions; no is the honest arm and no ADR-0087 marker is owed on a non-breaking changeset. The changeset text names the three reachable triggers, the piece rule, the MFA coupling and the alert migration; it matches the diff.

③ Boundary flags

• open_questions: empty — nothing to answer.
• Dev deviation, surface widened to three scripts/ files: the seat amended the claim in its ACCEPT (item 4 there); the widening is the rule's own prescription and the census copy and ledger row are gate-prescribed consequences — answered, right (① item 10).
• Dev deviation, outer catch warn → error: answered, right (① item 8).
• Dev deviation, attribution form: all four branch commits end with the model-free pair AGENTS.md names (Claude-Session: URL plus the bare Co-authored-by: Claude trailer) and the PR body ends with the session-URL footer; AGENTS.md wins over the harness reminder in this repo and the pre-push hook refuses a model identifier in the pair — answered, right.
• Dev deviation, check:pm-dispatch-gates run detached: read from its log at the head, exit 0; CI is the authority — answered.
• Two families NOT MEASURED locally on declared prerequisites (check:dual-build-cjs-loads, check:type-check-debt): CI answers — Type Check · debt ledger success, Build Core success; the repo-gates leg is in Lint & Repo Gates, still running at my last read (below).
• Out-of-scope finding (ordering inside one save, carrier none): judged ① item 11 — noted, not escalated; the pre-change behaviour was strictly worse and the residual is loud.
• Check-runs on 950c40c5 at 2026-09-28T11:13:45Z: 28 success, 3 skipped (Build Docs, Console Pin Gate, Packed-tarball smoke (opt-in)), 2 in progress (Lint & Repo Gates, Test Core (5/6)), 0 failure. Stated as read: the two running checks are not yet verdicts; the contract verdict below does not depend on them, the Tier S landing's every-check-green condition does.

Implemented-by: claude/issue-20412-auth-settings-sibling-isolation
Reviewed-by: session_017B6YKCGu8CTY2KBWgwaHAs

VERDICT: PASS

_{Rendered by an isolated contract-review subagent and adopted by the domain:services seat (#6021, session_017B6YKCGu8CTY2KBWgwaHAs) at 2026-09-28T11:16Z after a transcript check: 69 harness model stamps, all at CONTRACT_REVIEW_TIER, zero fallbacks; 34 Bash and 1 Read calls, one Write confined to its own scratch record, zero GitHub writes.}

---

Generated by Claude Code