[scotwells]

Summary

Release, reuse and custody: proposed documentation only. Select release-owned R1 closure, complete obligation inventory, qualified execution/network/data/credential settlement, accounting acknowledgment, R2 clearance and separate external R3/fresh reuse gates. Retain explicit adopted authorization and real-accounting or positive non-applicability proof.

Add PhysicalMaintenance clearance using the same ReleaseCase/slot and optional supply fields. Require permit/crew cessation, physical disposition, dependency-owner barriers and accounting provenance. Qualified passive policy does not fabricate boot/media/cleaning requirements. R2 clears only its subject, preserves destination interests and dependent obligations, and cannot publish eligibility. Add qualification cases 16–18.

Remaining P2 response and preserved boundaries

Responds to the exact fresh complete-set review. The earlier commissioning/adopted-settlement findings remain resolved in the proposed contracts; this revision does not replace them with maintenance.

• physical-maintenance-v1 adds one explicit subject to the existing shared custody/slot/journal/release protocol, not a second allocator or executor.
• Passive Device work has exact asset/resource/custody identity, current action/input authority, protected finite work inputs and one-use technician permits; no MachineCapacity, Machine, quota hold, Installation or bootstrap is invented.
• Active dependent devices and connections retain their own custody and writers. Their separately authorized, effective prerequisite fences precede field admission; target clearance cannot reset, disconnect, wipe or reconnect them.
• Unknown work, delivery, cessation, identity, accounting or physical clearance retains custody and conservative old/new interests. Restoration reconciles independent owner/field history and excludes old crews before any recovery authority.
• L5, R2, physical reservation disposition and fresh inventory eligibility remain separate. Observational adoption causes no effects. Catalog withdrawal blocks acquisition but does not revoke retained runtime capabilities; current action/input rights and separate suspension remain mandatory.

No runtime implementation, core #41/#51/#58/#59 change, managed-service scope, compatibility machinery, new PR, merge, watch or self-signoff. This existing branch remains based on origin/main at 8ebec19513a0cbc8f219d3acae46f89ab471510b; companion branch diffs are not imported.

Exact final complete-set manifest

PR	Exact final head
#41	f04e63ddd9d10cbf306daf3a0232961debd85e7f
#51	fa07c2236801a33a58efc914b555586c8e146cc6
#58	a922ff1eb3275e26af6ae750a7515ddde245a754
#59	d7ff793b03711203dbfc9fac87d43922cc649b6f
#60	80c72446a574202c9dac5f6d3c26ce4a0af875ba
#61	8101f645cc8167f71a07147e6ea1a9cdf69a57cf
#62	496ec4530aa3bacdb4858d0b22192be1a92b0c48
#63	ce4a30a36ee476073281b40b8353ac5eb2c99e0c
#64	4495e20f4c3ee7697dfd97a5a95823ca5fa7b448
#65	94824bf7ef614fcdecf3ce813c289e259367e90c
#66	ffe6ed28e261578bbc3d0226585b5e80f5d5985c

This PR's final head is 94824bf7ef614fcdecf3ce813c289e259367e90c. Core heads are unchanged. #60–#65 pin immutable contract-bearing snapshots; #66 pins their final source heads. Post-contract commits refresh only pins/review provenance, avoiding circular final-head dependencies. Older embedded pins in snapshots are drafting history, not authority to substitute an older contract for this aligned set.

PR	Immutable contract-bearing snapshot
#60	4bf770db8bd2b065748c3b9384d4c72f9b8ec0e1
#61	25fef48790b13da95900de64ffd2d1b36e0510eb
#62	4f9934980b3f441c1d777157fa0ba1dcfce372d7
#63	2b384517fd08c04cf078923ebda2cddcfa1dc424
#64	58a6596d30b3819d0b3799192730626439ef9885
#65	310a55d97394bb296c579bd3ad01177455c15cc4
#66	26601c7121542d7c89ddac84c1f8592f08cb8372

Documentation validation

• Combined all eleven revisions with temporary git merge-tree/commit objects only: conflict-free; no branch or PR merge and no shell worktree. Combined tree c5c26cf30c2ee1f974404576220c106ad32961f2, local validation commit 036e40a0573be61b506fff7e8604bac4377117a0.
• Repository link checker plus fence-aware validation: 48 Markdown files, 647 local targets, 355 local anchors, no missing targets/anchors or undefined explicit references. All 21 unique pinned Fleet source paths exist.
• 15 SVGs parse/render; both DOT sources render; all three PlantUML sources pass check-only; four JSON examples parse. Three changed SVGs visually inspected for clipping/layout.
• D01–D40, I1–I39 and N1–N23 have unique contiguous definitions. All preexisting D01–D35, I1–I35 and N1–N21 rows remain byte-for-byte unchanged. New scenarios are specifications, not qualification runs.
• Per-PR changes remain inside each intended enhancement directory; original unrelated branch changes preserved. Original supplied head is an ancestor of each published head. Per-PR and combined whitespace checks pass.
• External HTTP sources were not comprehensively revalidated. docs: propose standalone Metal network handoff #61's previously unavailable cloud attachment reference remains an explicit owner prerequisite, not an assumed integration.

Remaining prerequisites and review status

Fresh independent complete-set integration review is required for this exact changed manifest; no previous approval or author check signs off these revisions. Implementation still needs the shared ledger hooks and synchronous storage/restore interlocks, independent R/KMS/PKI and physical fences, registered owner gates, protected inputs/evidence, qualified online field permits and site/crew exclusion, active-custody/network owner agreements, accounting applicability proofs, measured profile limits and real qualification/drills. QP does not qualify compute or supplier execution. R-history-loss reactivation remains unsupported until separately implemented and qualified.

No runtime, hardware, provider, Q0/Q1/QP/QD/QE qualification, owner approval or independent signoff is claimed. Ready for the requested fresh independent review, not merge or deployment approval.

[scotwells]

CHANGES REQUIRED — proposed architecture review

Reviewed head: 64c3ed0ec355eadfb68b40b06c25a4717763e2b8. Fetched the actual PR head and refreshed it immediately before this verdict; it still matches. Scope: standalone Fleet/Metal only, not managed nodes/clusters, backward compatibility, or runtime/hardware/platform acceptance.

P2 — Catalog withdrawal must not close existing allocations' ordinary operation admission

Location: docs/enhancements/release-reuse/README.md:110–111, repeated ambiguously in the failure-matrix row at line 544.

The proposal groups catalog withdrawal with suspension/provider retirement and says it “closes ordinary admission.” In this protocol ordinary admission includes new operations, sessions and boot grants against an existing Allocation. That contradicts the pinned retained-capability contract: #58 lines 288–303 explicitly distinguishes acquisition withdrawal from runtime restrictions, and #59 lines 1107–1110 requires preserving retained runtime capabilities. #62's operation admission and #64's operation-authority sections preserve that distinction too.

Concrete counterexample: Allocation A is active with retained reinstall/power capabilities and valid current action/input permissions. Its provider removes the offering from the catalog to stop new sales, without suspending A or retiring the provider. An implementation following lines 110–111 closes A's ordinary operation/session admission, rejecting an otherwise authorized power operation or reinstall. Neither a release decision nor a runtime restriction exists. Merely avoiding erasure does not preserve the accepted contract.

Minimum fix: Split the triggers explicitly: catalog/offering/assignment withdrawal closes new acquisition only, leaving existing allocations' retained runtime capabilities and service cleanup intact; explicit suspension/safety restrictions close their specified affected runtime actions; provider retirement closes acquisition and ordinary runtime admission under ProviderGuard. Make the same distinction in the failure matrix, and add a scenario asserting that a currently authorized action on an existing allocation remains admissible after catalog-only withdrawal while a new allocation is rejected. No weakening of release's R1 closure is needed.

Adversarial coverage and qualification boundary

I read the complete release proposal and checked its relevant contracts against the pinned #41/#51/#58–#64 sources, including #59 PXE, plus AGENTS.md, README.md and architecture context. The concrete release traces otherwise fail closed: admission versus pre-closure sends is ordered and inventoried; late callbacks/outboxes/paused brokers and persistent BMC commands require boundary settlement; RAM installers require independent physical stop; session/console/PXE and cleaner access require effective revocation; #61's exact disconnect, durable no-reuse and per-assignment disposition barriers are consumed; missing/swapped media cannot be replaced by another disk's erase evidence; firmware/BMC restoration and old-credential denial remain separate predicates.

I also checked evidence expiry/invalidation before and after R2, shared ledger lock ordering, deletion with protected cleanup/key/input custody, quota acknowledgment independent of fresh reuse eligibility, permanent tombstones/new allocation identities, restore epochs and old-writer fencing, and external-provider LockedClean/R3/unavailability. I did not identify an additional concrete transition that permits premature reusable capacity under the stated qualification assumptions. Independent physical stop, trustworthy component coverage, irreversible downstream barriers, protected recovery infrastructure and provider emergency-access agreements are explicit enablement prerequisites—not claims of implemented or physically verified guarantees, and not findings merely because their implementations are deferred.

This is a request to correct a contradictory architectural contract, not a formal approval or runtime/hardware/platform sign-off. No repository edits or runtime tests were performed; git diff --check passed for the proposal diff.

[scotwells]

ARCHITECTURAL SIGN-OFF — proposed architecture only

Reviewed exact head: fae0cd3bf2a3a7e208c92c3e46c9b5670d877906. I fetched the actual PR head and refreshed both the Git ref and GitHub head immediately before this verdict; both still match. This is a fresh independent adversarial re-review of the complete proposal, not only the corrective diff. Scope: standalone Fleet/Metal, with no managed-node/cluster or backward-compatibility requirements. This is a top-level architectural comment, not a formal PR approval or implementation, hardware, security-certification, or production sign-off.

Prior P2 resolved

The authorization paragraph, lines 105–116, separate failure-matrix cases at lines 548–549, and qualification scenario at lines 561–565 now preserve the pinned #58/#60 distinction between acquisition access and retained runtime capabilities.

Replaying the original counterexample: an active allocation retains its accepted power/reinstall capabilities after catalog-only withdrawal; a currently authorized runtime action is not rejected merely because acquisition access disappeared. Withdrawal creates neither a runtime gate closure nor a ReleaseCase. A separately effective runtime suspension rejects its affected action, and provider retirement closes ordinary admission under ProviderGuard; neither alone authorizes wiping. R1's authorized irreversible release closure remains intact. The acquisition rule still consumes #58's effective combined-grant evaluation: removing one redundant assignment does not erase another valid grant.

Complete-protocol adversarial review

I found no additional architectural blockers under the stated qualification assumptions. In particular, the following attempted counterexamples remain blocked:

• Late mutation after release admission: a pre-R1 outbox or broker paused after SendMarked remains in the retained effect inventory; central closure is not physical quiescence. docs: concrete operation execution, fencing, and recovery #62 settlement and stale-writer fencing precede cleaning, using the same conflict slot rather than a competing release executor.
• Network isolation mistaken for sanitization: docs: propose standalone Metal network handoff #61's exact disconnect/no-reuse barriers and per-assignment disposition are separate from physical host-stop, persistent-task settlement and data treatment. A RAM installer or queued BMC command cannot be cleared by a network receipt. Cleaner-created service bindings and credentials must also settle before EffectsClosed.
• Wrong or incomplete hardware proof: a replacement disk's erase cannot discharge the missing original disk's obligation. Component identity, media coverage, firmware/BMC restoration, credential invalidation and no residual execution remain independent predicates. docs: propose inventory lifecycle and trust #63 owns trust/eligibility; release does not free physical placement reservations or silently retarget an allocation.
• Certificate/accounting race: invalidation before R2 retains occupied quarantine, including when quota has already acknowledged release. It does not fabricate a new charge or free capacity. Invalidation after R2 requires current safety authority and cannot reuse predecessor cleanup credentials against a successor tenant.
• Premature external reuse: docs: propose provider-neutral fulfillment protocol #64 LockedClean retains the provider lock through Metal quota settlement/R2; the explicit reuse gate and exact R3 acknowledgment prevent new reservation before provider finalization. Old cleanup/finalization cannot address a new reservation generation.
• Deletion, outage or restore erases responsibility: protected inputs, key versions, obligations and tombstones survive project API loss. Independent restore epochs require external old-writer fencing and union reconciliation; missing history remains quarantine. Provider retirement cannot purge unresolved custody, and broad custody transfer remains disabled.

I read AGENTS.md, README.md, the architecture context, the full release proposal, and relevant pinned contracts from #41, #51, #58, #59 including PXE, #60, #61, #62, #63 and #64. The #63/#64 interfaces remain draft dependencies, not owner approval.

Qualification boundary and validation

Independent physical stop/queue clearance, trustworthy media/component coverage, effective downstream barriers, protected journals/keys/restore authority, lifecycle/quota interlocks, and provider emergency-access agreements are explicit enablement prerequisites. Their deferred implementation is not itself a design hole: unsupported or unverifiable cases remain unavailable rather than being promoted to readiness. These obligations must be implemented and qualified before enablement; this review does not establish that they exist or work.

The complete proposal diff passes git diff --check; 14 local/pinned links, their anchors, reference labels and balanced fences validate against exact Git blobs. No repository edits, runtime tests, subagents, merge, watch, or formal approval were performed.