product/composition: persist immutable generation and activation authority

Buyer-visible gap

#432/#433/#434 currently prove only process-local product-composition admission. OwnerApiRelease, CompositionRoute, CompositionGeneration, and AdmissionReceipt construction/issuance integrity disappears across GC/process restart and therefore cannot prove which exact generation/configuration/deployment was historically active.

This issue owns the next Orgmetra product-composition persistence slice under #432. It is not a new bounded context and does not own HR domain truth. It may persist only immutable composition generation/configuration/deployment/activation/audit coordinates needed to prove exact product-composition state. It must not copy owner schemas, query owner application tables, or move Keyverse/domain authorization/idempotency/concurrency/scientific truth into composition.

Dependency boundary

Parent executable admission: feat(composition): admit exact released owner API routes #434, currently stacked on fix(ci): run setup-node on Node 24 action runtime #340.
Architecture authority: docs(gateway): separate shared edge transport from Orgmetra product composition #433 / ADR 0432 remains Proposed; this issue must remain Draft/dependent and must not be called protected or release-ready before normal architecture admission.
Canonical Foundation service discovery/runtime compatibility: ci: reconcile service Python runtime metadata and executable compatibility #260 after its declared prerequisites.
Positive activation ultimately requires released Keyverse/Orgmetra ACL and released owner API/operation evidence; synthetic structural fixtures are insufficient for production activation.

No mutable sibling source copy, feature-local quality workflow, cross-service SQL, force-push/destructive rebase, self-approval, gate weakening, or routine administrator bypass is authorized.

Durable invariants

Generation identity is non-reassignable. One generation_id is bound permanently to one schema/configuration meaning. Re-registering the exact same canonical generation is idempotent; reusing the ID for a different config_sha256 or route material fails closed.
Canonical configuration is reconstructable. Durable rows retain enough normalized route and owner-release material to reconstruct OwnerApiRelease/CompositionRoute/CompositionGeneration, recompute the canonical configuration digest, and run the existing feat(composition): admit exact released owner API routes #434 admission evaluator. A stored digest without reconstructable semantic material is not authority.
No partial generation becomes eligible. Generation root + route/release material are written atomically. Incomplete route sets, split owner releases, invalid Path Item ownership, path-selection ambiguity, or hash mismatch fail before commit/activation.
Deployment identity is explicit and non-PII. Deployment/environment coordinates contain no credential, Person, tenant, or other HR data and are not inferred from caller labels that can be reassigned silently.
Activation is generation-atomic and append-only. Current deployment state is derived from an append-only activation event sequence under a per-deployment transaction lock. Concurrent activations cannot both claim the same next state.
Rollback is a new activation event. It may target only a previously persisted immutable generation and must re-run durable generation/configuration/release/owner compatibility checks; a stale in-process AdmissionReceipt is never rollback authority.
Mutation history is not rewritten. Generation semantic rows and activation events are update/delete denied after insertion except for explicitly modeled append-only successor evidence.
Recovery is reproducible. After process restart the active generation can be reconstructed and re-admitted from durable rows without relying on Python object identity or prior closure state.
Composition-only persistence. No HR application table, owner-service table, Keyverse table, or cross-service SQL is introduced.

Implementation order

Start with a narrow child of #434 that defines the immutable durable generation/configuration registry and its PostgreSQL adapter/contract tests. Then add deployment activation/rollback event semantics on the same owner path. Keep the issue open until both persistence and activation/recovery are exercised under canonical Foundation/PostgreSQL acceptance on a protected-base candidate.

Acceptance

GREEN requires executable RED coverage for generation-ID reassignment, partial writes, route-material/digest mismatch, forged stored release coordinates, concurrent activation conflict, stale rollback evidence, update/delete attempts, and restart reconstruction; exact-head 100% owned statement/branch/docstring/edge evidence; isolated PostgreSQL acceptance; failure/recovery evidence; normal Security/SAST/CodeQL/review governance; then protected integration and immutable Orgmetra release evidence. None of those are inferred merely from this issue or a Draft child PR.

Refs #432 #433 #434 #260.

First dependent implementation lane opened as Draft #436. Current exact child head is 80932c808ef873b268217ef1b79b0d14fd8884f7, base #434 exact 68bdf2d984ca7686219c335a85a6574195675cbe, 6 commits / 3 files and mechanically mergeable.

The first commit 1603ed6... is source-deterministically RED because it imports a registry module absent from its parent. Current source adds normalized, reconstructable generation / owner-release / route / route-method record values, canonical receipt revalidation before projection, fresh #434 value reconstruction, configuration-digest recomputation, and fail-closed corrupt-reference tests. 7354287... removed unreachable branch debt; 80932c8... expands exact-type/reference/digest/split-owner edge coverage.

No migration or PostgreSQL adapter is claimed yet. Next causal increment remains the issue-defined persistence boundary: atomic registry tables/adapters, durable generation-ID non-reassignment, restart reload/reconstruction/re-admission, partial/tampered-state rejection, then append-only deployment activation/rollback.

2026-09-22 durable-registry increment currentization

Draft #436 has advanced from the persistence-neutral record contract to exact 04705a05f8e4fd58a39527f56dcb993fd4bb40cb (14 ordinary-forward commits / 8 files), still directly stacked on #434 exact 68bdf2d984ca7686219c335a85a6574195675cbe.

Implemented in the Draft source:

normalized append-only PostgreSQL generation / owner-release / route / route-method persistence in migration 0018_product_composition_generation_registry.sql;
one-connection atomic adapter registration with generation-PK conflict arbitration and exact-material-only idempotent replay;
restart load -> fresh feat(composition): admit exact released owner API routes #434 value reconstruction -> canonical config_sha256 recomputation;
fail-closed partial/tampered durable material;
real PostgreSQL contract source covering registration, reassignment rejection, append-only UPDATE/DELETE rejection, and partial-transaction rollback. The contract is executable in Git mode.

Migration 0018 is deliberate because active unmerged migration-owner lanes already occupy 0014-0017; no number was stolen from those lanes.

This closes the Draft-source implementation gap for durable configuration material only. It does not close this issue. Deployment/environment identity, append-only activation sequencing, deterministic concurrent activation conflict, rollback-as-new-activation, restart derivation of the active generation, canonical PostgreSQL/Foundation execution, review/security gates, protected adoption and immutable release evidence remain open.

Exact #436 currently has zero PR-triggered workflow runs and no submitted review/thread evidence, so no GREEN/Ready/protected claim is made. Next causal increment stays on this owner path: activation/rollback/recovery over persisted generation authority, not another process-local admission micro-invariant.

Fresh owner-path update:

feat(composition): persist reconstructable generation registry #436 advanced ordinary-forward to exact 98b4b129073a2afc70f8a533e34c31fdcc15ab07. A persistence audit found that migration 0018's row-level UPDATE/DELETE guards did not protect PostgreSQL TRUNCATE, so its append-only claim was incomplete. 86c0bffe... adds static + real-PostgreSQL TRUNCATE RED contracts; 98b4b129... adds BEFORE TRUNCATE guards on all four generation-registry relations.
The pre-existing feat/product-composition-activation-registry branch was reviewed rather than overwritten. It was already a direct descendant of feat(composition): persist reconstructable generation registry #436 and implemented migration 0019, per-deployment FOR UPDATE serialization, append-only activation sequence, rollback-as-new-event and restart reconstruction. After feat(composition): persist reconstructable generation registry #436 advanced it adopted the exact parent by ordinary two-parent commit 2ba5f65b... with no force/rebase.
Draft feat(composition): persist deployment activation authority #437 now owns that activation slice at exact 692d679a2d4b7234003cd25111f0b4078214e397. 040daf34... -> 01cbb84a... closes the same TRUNCATE erasure path for deployment/event history. cde1fecf... -> 89b77496... closes valid-to-valid process-local DeploymentIdentity retargeting before database access; the durable composite key + row lock remains cross-process authority.

Important remaining #435 gap from exact source review: #437 reconstructs a persisted generation before activation/recovery, but that only proves internal durable configuration integrity. It does not yet bind a positive activation/recovery decision to fresh released Keyverse/Orgmetra ACL evidence plus fresh observed owner-API/operation evidence. Therefore #437 remains structural durable activation state, not production activation authorization.

Next causal increment should integrate those released/versioned authorities fail-closed while keeping external/network resolution outside the per-deployment transaction lock, then bind the exact evidence used for the decision so restart/recovery can re-admit rather than merely reconstruct. Do not solve this by copying Keyverse/owner schemas or by calling remote owners while holding FOR UPDATE.

No hosted exact-head GREEN or independent approval is claimed for #436/#437; #260 still owns canonical service/PostgreSQL discovery and runtime acceptance.

2026-09-22 currentization: #437 has advanced beyond structural activation and now represents transaction-bound external evidence persistence/freshness plus durable recovery lineage and a product-surface boundary. Exact child head is 60e184fd1edc3e16ee5637929015769cb3e01855, stacked on #436 exact 98b4b129073a2afc70f8a533e34c31fdcc15ab07, fresh compare 44 ahead / 0 behind.

Two fresh authority defects were repaired ordinary-forward. First, structural activation events intentionally may have evidence_bundle_sha256 = NULL for migration/fault testing, but product-facing recovery could previously obtain fresh external allow evidence and promote that unauthorised durable history. Sequence d4b768fc... -> 28fef4b4... -> 10898ab5... -> fe6be5ad... -> 270a2b70... -> faaee012... -> 7d936963... now carries the historical digest through ActivationEvent, rejects NULL-evidence history before any remote verifier call, and keeps fresh restart evidence separate from historical transition evidence.

Second, the structural PostgresActivationRegistry was still re-exported from the root package, making the evidence-bypassing migration/fault primitive look like a supported product entrypoint. Sequence f7dbfdeb... -> 8ca291cd... -> 39e39676.../68ac1091.../5ba4d343... -> 60e184fd... removes it from the package product API, leaves structural tests on the internal module, and documents AuthorizedPostgresActivationRegistry as the positive product entrypoint. This is API-boundary hardening, not a hostile-code sandbox claim.

The earlier transaction-time gap is no longer the next implementation gap: migration 0019 persists/verifies exact non-PII evidence under the activation transaction and uses clock_timestamp() after row-lock wait to reject expired/incomplete owner-operation coverage. Keep #435 open because buyer-ready acceptance is still absent: canonical #260 execution of this package/PostgreSQL roots, protected exact-head coverage/security/review evidence, actual immutable Keyverse/Orgmetra/owner releases, deployable HTTP composition host, and end-to-end performance/recovery evidence remain outstanding.

Fresh #437 owner-path update: exact head is now 54a61d0673a2b9702f9c8306473543598c755288, 46 commits / 16 files, still directly stacked on #436 exact 98b4b129073a2afc70f8a533e34c31fdcc15ab07 with merge-base equal to the parent and 0 behind.

Fresh review found a local-authority boundary defect in the external re-admission path. PostgresGenerationRegistry.load() reconstructs a canonical CompositionGeneration, but the caller-supplied evidence provider receives that object before activation. ActivationAdmissionEvidence.validate_for() previously checked only its exact type/current fields. A provider could therefore use low-level object.__setattr__ to retarget the loaded generation to another individually valid generation ID while returning matching evidence, allowing external verification code to redefine the local durable target before structural activation.

Ordinary-forward repair:

d480d4628b264ba69282efa6da8432b61054d645 adds the RED contract: requested generation_one retargeted by the provider to valid-looking generation_two must fail before the structural registry is reached.
54a61d0673a2b9702f9c8306473543598c755288 revalidates the canonical generation construction snapshot before invoking the provider and again from ActivationAdmissionEvidence.validate_for() after provider return.

This keeps authority directional: external released ACL/owner evidence may evaluate Orgmetra's exact durable generation, but it may not redefine which generation Orgmetra is activating. The change is process-local integrity hardening, not a Python hostile-code sandbox claim.

No exact-head hosted pytest/PostgreSQL/coverage/Foundation/Security/SAST/CodeQL or independent review is inferred from these commits. #437 remains Draft; real immutable Keyverse/Orgmetra/owner release evidence and canonical execution remain open acceptance requirements.

Fresh #437 authority finding/repair handoff: predecessor 54a61d0673a2b9702f9c8306473543598c755288 bound external re-admission to deployment + target generation but did not structurally bind the external decision to transition kind or durable state version. A fresh evidence bundle could therefore be semantically replayed as activate vs rollback, or after another writer advanced the deployment, until the structural sequence guard rejected only the state race; the external decision itself remained generic. Ordinary-forward sequence now starts with RED fb34eb2b693f0033311050f2a6958db917dd79d1, adds provider/evidence action+state binding in fc3308640a732e63867fc99630158af5598b4140, adds durable PostgreSQL enforcement in e928a1c0560fd4d0058edade0d785036f6d20590, updates existing/recovery contracts and a native PostgreSQL wrong-action rejection, and currentizes docs/public API through exact #437 79a109acd91b38f58371eb5f8174dda3e2423009. Provider probes remain outside FOR UPDATE; DB event insertion now requires evidence action == event kind and evidence authorized-state-sequence == activation-sequence - 1, then rechecks expiry/owner coverage. Keep #435 open: exact-head canonical execution/review and real immutable Keyverse/Orgmetra/owner release evidence remain absent; this is not shipment authority.

Fresh #437 review found that predecessor 79a109acd91b38f58371eb5f8174dda3e2423009 still left product_composition_activation_event.evidence_bundle_sha256 nullable. That meant direct durable activate/rollback rows could be appended without external authorization evidence even though the product API used AuthorizedPostgresActivationRegistry.

Ordinary-forward repair now on #437:

e128da1be750dc3c0ed121981ed6208c351d1ea5 — RED contract for current-schema mandatory evidence.
501dbfb23e1b9d30aa2846d4fcbbacb2f8bb6b1a — migration 0020_product_composition_activation_authority_enforcement.sql; fails closed if historical NULL-evidence events exist, then sets evidence_bundle_sha256 NOT NULL.
333cd76a9cfb683550e8fcf6b20dbe954ed60234 + db91f4ff6bd554434f7faaf6b3dd82833d0eda56 — executable native PostgreSQL contract proving unauthorised NULL-evidence activation is rejected while evidence-bound activation remains admissible.

Owner invariant for #435 is therefore stricter: structural NULL-evidence transitions may exist only as predecessor-schema/unit/migration/fault fixtures; the current durable production schema must require exact evidence attribution on every activation event. Existing prerelease databases with such rows must stop migration for explicit reconciliation rather than silently grandfathering them.

Fresh owner-path update: Draft #437 advanced ordinary-forward from db91f4ff6bd554434f7faaf6b3dd82833d0eda56 to exact 2cc217bf07dedb9ebd61bfa95d776b0062b319d6 (61 commits / 21 files), still directly stacked on #436 exact 98b4b129073a2afc70f8a533e34c31fdcc15ab07.

Fresh review found a separate process-local evidence-integrity defect. ReleasedAuthorityEvidence, OwnerOperationObservation, and ActivationAdmissionEvidence were frozen dataclasses but could still be valid-to-valid retargeted with low-level object.__setattr__ after construction; current validation checked their current shape/coverage/freshness, not their original construction identity. That allowed an already-created external authorization object to be reinterpreted as another syntactically valid authority release, observation, or authorization-decision digest before durable attribution.

Ordinary-forward repair:

eaeab4941da0169551dc27e0dc3cf6570a325f60 adds RED regressions for released-authority, owner-observation and activation-evidence retargeting.
2cc217bf07dedb9ebd61bfa95d776b0062b319d6 adds closure-private weak-reference construction snapshots for all three value types and revalidates nested evidence at admission, digest projection, row projection and durable persistence boundaries.

This is deliberately process-local integrity only; PostgreSQL rows, immutable release coordinates and transition/coverage constraints remain cross-process authority. A new semantic authorization decision must be a new value object/content-addressed bundle rather than mutation of an existing one.

#435 remains open. Exact #437 still has zero PR-triggered workflow runs and no qualifying independent review, so pytest/PostgreSQL/coverage/Security/SAST/CodeQL GREEN is not claimed. #260 remains the canonical package/service/PostgreSQL execution owner.

2026-09-22 currentization: #437 is now exact ed766da25564fea961e2076882599bac9085f07e, stacked 71 ahead / 0 behind on #436 exact 98b4b129073a2afc70f8a533e34c31fdcc15ab07.

Fresh durable-authority finding: the Python re-admission layer already rejected OwnerOperationObservation.observed_at_unix_ms values later than its current clock, but predecessor PostgreSQL truth (through 0020) did not. A direct database writer could therefore persist an exact owner-operation observation claiming knowledge from the future and retain it as activation evidence.

#437 repairs this ordinary-forward with migration 0021_product_composition_activation_observation_wall_clock.sql: fresh owner observations are rejected when observed_at_unix_ms > PostgreSQL clock_timestamp() or when already stale at insertion. The migration also refuses to upgrade predecessor history containing impossible future-dated observations instead of silently grandfathering them. Historical rows that are merely expired are retained as immutable history; current event admission already prevents reuse after expiry.

Current schema order for this owner path is now 0018 -> 0019 -> 0020 -> 0021. Native current-schema and upgrade contracts are tests/test_product_composition_activation_observation_wall_clock_postgres.sh and tests/test_product_composition_activation_observation_wall_clock_upgrade_postgres.sh, both executable at the current head. This remains Draft implementation evidence, not protected/buyer-ready authority: canonical #260/#311 execution, exact-head coverage/gates, qualifying review, and real immutable Keyverse/Orgmetra/owner release evidence are still required.

Fresh #437 review found a durable recovery-lineage gap: predecessor recover_active() obtained fresh authorization_action='recover' evidence and rejected concurrent state change, but the successful restart re-admission existed only in the returned Python value. It vanished on process exit, so durable history proved the historical activation decision but not which fresh external evidence re-admitted that state.

Ordinary-forward owner repair is now on #437 exact 27b82cc74a60838d57d31aa0a2ed3a131b243b95: RED e34c207...; migration 0022 f6e6d17... adds append-only product_composition_recovery_attestation; 5a61fa0... adds locked structural recover_active_authorized(); 60f0928... wires product recovery to persist fresh evidence + attestation only after exact active sequence/generation recheck; regressions 34174aa.../6d2ce43...; native PostgreSQL contract bddaec1..., executable-mode 94accd7...; static DB contract 27b82cc....

Current schema lineage is now 0018→0019→0020→0021→0022. Remote verification remains outside the deployment lock; the DB lock is used only for exact-state recheck, evidence persistence and attestation append. Keep #435 open: no hosted exact-head GREEN, real immutable external release evidence, protected integration or buyer-path acceptance exists yet.

Fresh durable-authority finding repaired on #437.

Exact head is now 012c90889ea78db4baa18a2a7973717d00301be1 (84 ahead / 0 behind #436). Review found migration 0021's predecessor-history check was not atomic with installation of its permanent wall-clock INSERT guard: the DO preflight and later CREATE TRIGGER ran as separate autocommitted statements, so a concurrent predecessor-schema writer could insert future-dated owner evidence after the scan and commit while trigger creation waited.

Ordinary-forward repair: 0c4e497... RED requires an explicit transaction + writer-conflicting fence; e61fdcc... wraps 0021 in BEGIN/COMMIT and takes SHARE ROW EXCLUSIVE before the scan through trigger creation; 012c908... converts the native upgrade contract into a concurrent-writer case that distinguishes the fenced migration from the predecessor behavior.

The policy itself did not change: future-dated owner observations remain impossible durable authority. This repair makes the upgrade path enforce that claim under concurrency. Keep #435 open: exact-head canonical execution/review, actual immutable external releases, deployable composition, recovery/fault/security and buyer-path performance acceptance are still outstanding.

#437 fresh owner handoff: exact 03eb4b0861a4f1de07c9b66c20f71ab28d378559 adds a source-deterministic RED (7d4ef88e...) and causal repair for migration 0022 publication atomicity. The recovery-attestation table previously became visible after CREATE TABLE before its INSERT/append-only/TRUNCATE guards were installed because 0022 used separate autocommitted DDL statements. A concurrent session could therefore grandfather durable recovery rows that current 0022 policy would reject. 0022 is now wrapped in one explicit BEGIN/COMMIT, so external sessions see either no relation or the fully guarded relation. This hardens upgrade authority only; #435 remains open until canonical exact-head PostgreSQL/coverage evidence, immutable external release evidence, protected integration, and release evidence exist.

Owner handoff after fresh durable-authority review: configuration parent #436 advanced ordinary-forward to 6ebe5ec72ddb5d13b8550064cfc33ff1861d39e3 after RED 2c26cbf... proved migration 0018 could publish generation tables before append-only/TRUNCATE guards under autocommit. 0018 is now one explicit BEGIN/COMMIT publication unit. Child #437 was non-force restacked on that exact parent, then advanced to c8886e605e65779f38c813635954546f3e4431a4 after RED a28882e... proved the same publication gap in 0019 activation/evidence/event schema; 0019 now publishes tables/functions/lineage+append-only+TRUNCATE guards atomically. Fresh compare #436→#437 is 91 ahead / 0 behind, merge base exactly #436. Keep #435 open: these are Draft hardening changes, not protected/released activation authority.

Fresh #437 authority finding/repair: predecessor 0020 (product_composition_activation_authority_enforcement.sql) scanned for NULL-evidence activation history and published evidence_bundle_sha256 NOT NULL as separate autocommit statements. A predecessor-schema writer could therefore cross the scan/publication boundary; the ALTER still failed closed on a NULL row, but the preflight no longer represented the state being promoted. #437 ordinary-forward commits cc8486c896725b3421a8f43e10658f786c78daa5 (RED) -> fb362d554ab5c0cb2b3c2611aa0d4fa7314e1b32 (fix) now wrap 0020 in one transaction and acquire SHARE ROW EXCLUSIVE on product_composition_activation_event before preflight, held through SET NOT NULL. Keep #435 open: this is migration-authority hardening, not canonical exact-head PostgreSQL/coverage/release evidence.

2026-09-22 durable-authority handoff: #437 ordinary-forward exact 035826c9ddb1534290d8ed7957da3c5a45b80da4 adds migration 0023_product_composition_deployment_write_serialization.sql. Fresh review found DB DML was weaker than the application adapter: activation-event INSERT and recovery-attestation INSERT validated different target tables without first contending on one shared deployment-row lock, so concurrent direct SQL could validate against the same predecessor deployment state. RED 2d1d63b...; causal migration d2d78584...; deterministic PostgreSQL lock-wait contract f96798f...; executable-mode successor d8bbf748...; current-schema recovery contract 035826c9.... Current migration order is 0018→0019→0020→0021→0022→0023. Keep #435 open: this closes one serialization gap only; protected exact-head execution, real immutable external authority, HTTP host, recovery/security and buyer-path evidence remain missing.

Fresh durable-authority handoff after parent review: configuration owner #436 is now exact 5fd0087179f2e6f23f2bb3853ad1de397fc53b0e (21 commits / 11 files). Review found that 0018 still created generation-authority relations and bound mutation/TRUNCATE guards through migration-session search_path, even though downstream #437 had already hardened activation/recovery trigger provenance. Ordinary-forward owner repair is 8e0d6b63... RED -> c79eb138... causal migration fix -> 5fd00871... hostile PostgreSQL contract. 0018 now pins its migration search path, publishes generation/owner-release/route/route-method in trusted public, uses public-qualified FK targets, and binds all eight generation mutation/TRUNCATE triggers to explicit public functions. The PostgreSQL contract installs decoy guard functions ahead of public in caller search_path and requires relations/bindings to remain trusted while destructive update still fails closed.

Child #437 was then descendant-restacked normally, not force-pushed: merge/adoption commit 468dab6d8be4cdd8467b5093434e4756ce1ce9b0 has old child 84d347b... and new parent 5fd0087... as parents. Fresh compare is 111 ahead / 0 behind with merge base exactly #436. It retains 0019→0024 activation/recovery authority, deployment-row serialization, and 0024 trigger-function provenance.

One further acceptance gap is now explicit rather than hidden: older Draft activation migrations predate the parent search-path repair. The final ordered 0018→0024 candidate must be exercised under hostile caller search_path and prove no composition authority relation/function is redirected outside trusted public; the 0024 trigger-OID test alone is not evidence for the whole migration-runner chain.

Keep #435 open. #436/#437 still have no PR-triggered hosted execution or independent approval, no canonical exact-head PostgreSQL/coverage evidence, no real immutable Keyverse/Orgmetra/owner positive evidence, and no protected/released buyer path.

Durable-authority finding/repair refresh: #437 exact 1f63bb2bb97215a6f3e688582fe187734588b534 closes the fresh-install migration-schema provenance gap that remained after #436 fixed generation migration 0018 and #437 migration 0024 fixed final trigger-function provenance. Executable RED 0f7d96fb9619b57ab32190dd1b35ca2316936740 runs 0018→0024 in one hostile caller search_path; predecessor 0019 could create activation authority relations/functions through caller schema, and 0021/0022/0023 could create their guard functions there before 0024. Ordinary-forward repairs now pin transaction-local search path and explicitly qualify owned public objects/functions/trigger bindings, with static contracts currentized through 1f63bb2....

This is Draft hardening, not buyer-visible completion. Exact-head canonical PostgreSQL/pytest/coverage and independent review are still required; do not close #435 or treat final 0024 rebinding alone as full migration-chain provenance evidence.

Owner handoff from #437 exact 963433e2e6b527fbc0bdcbf4bf4a1a3fb5979b98: fresh review found a durable-authority gap below trigger-function provenance. PostgreSQL object ownership carries non-grantable alter/drop authority, so split ownership across deployment/evidence/observation/event/recovery relations can weaken one table independently even when 0024 binds trusted trigger functions. Ordinary-forward sequence: 1c5e45e... source RED → 2ea4a36... migration 0025_product_composition_activation_relation_owner_provenance.sql → ea24465... hostile PostgreSQL owner-drift contract → current-schema/full-chain/recovery/serialization currentization through 963433e.... 0025 locks the five activation/recovery relations, requires one owner equal to public.product_composition_deployment, and fails closed without silently ALTER ... OWNER. Migration order is now 0018→0025. This is Draft hardening only; no protected/release GREEN is claimed.

#437 ordinary-forward owner-path update: exact head is now fba4d57dd416b99b50807666b98fef9cc791f655 (Draft, 138 commits / 40 files, #436 5fd0087... +138/−0). Two findings were repaired in this run. First, ff7c392...→db4c49c...→7131550... closes a checked-vs-used process-local gap where the caller-supplied pre-lock evidence provider could retarget clock_unix_ms or nested PostgreSQL adapters after construction; the package-root positive registry now keeps closure-private construction identity over those executable capabilities. Second, predecessor 0025 only required the five activation/recovery relations to agree with product_composition_deployment, so uniformly transferring all five to one foreign owner could become self-consistent. d207634... adds the hostile PostgreSQL RED, 9a0d520... the static parent-owner RED, 133696d... anchors 0025 to the locked parent product_composition_generation owner, and fba4d57... currentizes package documentation. No ownership drift is silently repaired. These are Draft authority hardenings only; keep #435 open until canonical exact-tree service/PostgreSQL execution, real immutable external evidence, independent review/security gates, deployable host and protected/release evidence exist.

Durable-authority owner-path currentization for #437 exact c47957e046ceede37462a2dbccfa19c04d9c1dcf on #436 5fd0087179f2e6f23f2bb3853ad1de397fc53b0e (169 ahead / 0 behind, Draft).

The checked-as-used adapter repair remains test-first 9f859aa08d2aec00971f9efe630d0953d313414d → causal fix 1ec5cef18158bb1da84215ce55e76228ce5a73a0: the product wrapper pins the exact generation/structural adapter across the final capability guard→use boundary and preserves the no-post-commit-false-failure rule for activation/rollback/recovery.

Fresh review also converted the docstring warning into an owner-scoped enforceable contract rather than chasing a bot-wide percentage. ca9b0ef9581cfc6476ca2005821a6935229f739f AST-checks every function in the three activation-owner production modules. ab032d6028ffb34ee610bd8932fe3fcf6c011cb5 and c47957e046ceede37462a2dbccfa19c04d9c1dcf add meaningful production docstrings only; their commit diffs contain no executable-code changes. This is source evidence, not canonical pytest GREEN; #260 must execute the new contract and prove 100% owned production docstring coverage alongside statement/branch/edge evidence.

The prior weak-reference capability identity/lifetime, same-object clock-rewind, migration namespace/provenance, deployment serialization and relation-owner repairs remain intact. PostgreSQL remains commit-time authority. #311 must execute the unchanged 0018→0025 PostgreSQL roots from the same exact candidate as #260.

#435 remains open until canonical exact-tree package/PostgreSQL execution, immutable external release/evidence, independent review/security gates, production runtime/migrator role evidence, deployable host, protected integration and release evidence exist. Migration 0026 remains occupied by active Employment-absence PR #114.

Durable-authority owner-path currentization: #433 source remains exact 6fc85e4d8bb273adb0d5866d87554067c749179d, ADR 0432 Proposed/Draft. Live implementation is now #436 exact 3279977c59b9e1454897a8bc0beb392ec406c784 and #437 exact d7488cb0477651b04b3e5025c4d58f04e40d3751, fresh 180 ahead / 0 behind with merge base exactly #436.

Fresh generation-owner review closed two exported-registry capability defects. Public default load()/register() could previously redefine authority from a low-level-retargeted connection_factory; RED b6f69622... → ee87b64... construction-binds that capability and requires zero replacement calls. The first witness retained the admitted factory strongly, which could root a factory↔registry callback cycle; lifetime RED 13bfe26e... → final 3279977... uses weak identity evidence and fails closed for non-weak-reference factories. #437 adopts both parent repairs ordinary-forward/non-force via d7488cb...; migration lineage remains 0018→0025 and no DB migration was added.

The architecture principle is now precise across lifetime as well as use: public generation construction identity, nested adapter/factory identity, provider/clock identity, and PostgreSQL commit-time authority are separate evidence layers, and identity bookkeeping must not alter capability lifetime.

The residual production-security condition remains: 0025 relation-owner provenance is not production runtime/migrator least privilege. Keep #435 open until #260/#311 produce canonical exact-tree package/PostgreSQL execution and 100% owned evidence, #433 source adopts final admissible exact SHAs with fresh checks/independent review, immutable external authority evidence exists, deployment DB-role/fault/recovery acceptance is proven, a deployable HTTP host exists, and protected/release buyer-path evidence is complete. Migration 0026 remains owned by active Employment-absence PR #114.

Durable owner-path currentization after the recovery chronology repair:

#436 remains exact 30d89fa8f4ba95d7ddb84dde8e3b7e5faebf0343; immutable configuration still preserves required/optional admission semantics without claiming positive availability for an unobserved optional owner.

#437 is now exact e57195d1cb33c9289093e7bf0885c67f0ca80ff8, ordinary-forward 243 ahead / 0 behind the same parent. The adopted history still contains durable-observation collation normalization, no-post-commit-false-failure recovery semantics, exact recovery-sequence propagation/binding into serving snapshots, durable-attestation/current-activation serving checks, detached structural deployment identity before callback-capable DB use, and canonical internal/public route-ID projections.

Fresh review found a distinct durable-authority defect in the serving chronology boundary. current_route_ids_for_snapshot() treats the durable recovery attestation's recovered_at as the lower bound for database-clock rewind detection, but the relation allowed an otherwise-valid writer to explicitly supply that timestamp. A stale year-2000 value could therefore weaken rewind detection despite valid recovery action/state/evidence.

PostgreSQL RED 01096f4753fcf8fd511f0d1240e502012c6c60f8 extends test_product_composition_recovery_attestation_postgres.sh with that hostile insert and requires stored recovered_at to be fresh database-owned time. Repair e57195d1cb33c9289093e7bf0885c67f0ca80ff8 changes the final unreleased 0025 recovery validator to sample one recovery_wall_clock := clock_timestamp(), derive the validation epoch from the same sample, and overwrite NEW.recovered_at. Thus the persisted rewind anchor and evidence/operation freshness share one PostgreSQL wall-clock observation. No post-commit application check, new migration number, or copied owner truth was introduced.

#260 must canonically execute the package from this same exact candidate with route-order, structural deployment-identity, recovery-sequence/attestation currentness, snapshot integrity/currentness, optional-route, capability-integrity, recovery-commit-boundary, docstring and exact 100% owned statement/branch/edge coverage contracts. #311 must execute 0018→0025 from that same exact candidate and include the strengthened recovery-attestation hostile caller-timestamp acceptance alongside hostile namespace/upgrade/recovery/serialization/provenance roots.

#433 source remains exact 6fc85e4d8bb273adb0d5866d87554067c749179d, Proposed/Draft, and must later adopt final admissible #436/#437 SHAs while distinguishing canonical projection, recovery-commit snapshot authority, database-owned recovery validation time and request-time durable dispatch currentness.

Keep #435 open. Source RED→repair is not canonical GREEN. Completion still requires exact-tree package/PostgreSQL execution and 100% owned evidence, current architecture source with fresh checks/independent review, immutable external authority evidence, deployment DB-role/fault/recovery acceptance, a deployable HTTP host, protected integration and release/buyer-path evidence. Migration 0026 remains owned by active Employment-absence work.

Fresh durable/serving/request authority handoff: configuration owner #436 remains exact 30d89fa8f4ba95d7ddb84dde8e3b7e5faebf0343; activation/recovery/serving child #437 is exact 8a67b5cef24332619b3a4466e3787a851c299215, ordinary-forward 258 ahead / 0 behind with #436 exact as merge base. Request-routing descendant #438 is now exact d642eb71c05ae3990349a26facf30593a5703914, 7 ahead / 0 behind #437 with #437 exact as merge base.

#437's current database hardening keeps ordered lineage 0018→0025 and closes the evidence-lifetime mismatch between application and final PostgreSQL validators: RED 0e4d0b2e... / repair 2311c0de... require activation/recovery bundle expiry not to outlive any owner-operation observation used for serviceability, with activation-side observation time also bounded by the DB wall clock. No later migration number is taken.

Fresh #438 review found a separate request-boundary defect. The first resolver preserved concrete-before-template semantics but called current_route_ids_for_snapshot() before proving that a canonical request selected any declared Path Item/method, so known-unroutable traffic still crossed the PostgreSQL currentness boundary. RED ef991ff83a301aacf38a3157a1ad9bb995699ca8 makes unknown declared paths and undeclared methods fail if the DB factory is touched. Repair d642eb71c05ae3990349a26facf30593a5703914 resolves canonical path/method authority first, pins the selected route ID, and only then performs #437 durable currentness/availability. This reduces avoidable DB work without weakening snapshot integrity, concrete precedence or fail-closed availability. #438 adds no migration bytes.

Keep #435 open. These are Draft source contracts, not canonical package/PostgreSQL GREEN or protected/released serving authority. #260 package execution and #311 PostgreSQL execution must use the same unchanged exact #438 candidate; #433 source remains Proposed/Draft and must later adopt final admissible heads. Remaining acceptance still includes exact-tree 100% owned statement/branch/docstring/edge evidence, independent review, immutable external Keyverse/Orgmetra/owner evidence, production DB-role/fault/recovery and supported restore/failover evidence, a deployable HTTP lifecycle/transport/owner-execution path, protected integration and full buyer-path p95≤20 ms performance.

Durable-authority owner-path update: request-routing child #438 remains exact d642eb71c05ae3990349a26facf30593a5703914; new Draft transport child #439 is exact 2256112d09a7130cd361264eda8303b12d7ad027, ordinary-forward 5 commits with #438 exact as merge base.

#439 does not move durable generation/activation/recovery truth out of #436/#437. It binds ASGI raw request-target evidence to #438's decoded canonical route contract before request selection: exact HTTP scope, mandatory raw_path, empty query/root path, admitted ASCII raw bytes and exact raw/decoded path identity. It adds no migration bytes and no DB authority. Buyer-ready host/auth/owner execution/lifecycle/performance remain open; keep #435 open and require canonical package/PostgreSQL execution on one unchanged #439 candidate.

Owner-path currentization after the latest HTTP standards repair: durable configuration remains #436 30d89fa8f4ba95d7ddb84dde8e3b7e5faebf0343; activation/recovery/currentness remains #437 8a67b5cef24332619b3a4466e3787a851c299215; request routing remains #438 d642eb71c05ae3990349a26facf30593a5703914; raw ASGI request-target normalization remains #439 2256112d09a7130cd361264eda8303b12d7ad027; Draft #440 is now exact 98f8f464076a4182ddc02bc7fb34901597807b03, 11 ahead / 0 behind #439 with #439 as merge base.

#440 still does not change durable authority. Its host-facing projection now covers both previously documented error semantics and the RFC 9110 HEAD rule. Fresh RED f635fed9c9fc086ad7df6a5d8670563f3afad69b proves the predecessor sender emitted problem content for HEAD; repair 6e0555c400b2cda7d435e036d0a45417af524f6e makes request method explicit at ASGI emission and suppresses content only for exact built-in HEAD; 98f8f464076a4182ddc02bc7fb34901597807b03 covers malformed/non-string method behavior so invalid requests still receive the mapped 400 problem body. Existing 405 Allow, 503-without-invented-Retry-After, non-disclosure and foreign-error rejection remain intact.

This is not buyer-ready serving. Authenticated Keyverse/Orgmetra subject+tenant+purpose context, owner HTTP dispatch, request-body/disconnect/cancellation lifecycle, snapshot reload/invalidation, production runtime/migrator role separation, canonical package/PostgreSQL execution, deployment/recovery rehearsal and full buyer-path p95 remain open. Keep #435 open; source RED→repair in #440 is not protected/released authority.

Owner-path currentization: durable/configuration authority remains #436 30d89fa8f4ba95d7ddb84dde8e3b7e5faebf0343; activation/recovery/currentness remains #437 8a67b5cef24332619b3a4466e3787a851c299215; serving descendants remain #438 d642eb71c05ae3990349a26facf30593a5703914 → #439 2256112d09a7130cd361264eda8303b12d7ad027 → #440 d8f161af80e2e9bcbd15a51c3d248798b839f4ce → #442 d58dc07034082a18a5de6c9f4df03d40b096a72f → current #443 52a2fa0e6f2910e09d689d1985f8955db9b53e2e.

#443 remains downstream request lifecycle work only and changes no SQL; PostgreSQL lineage stays 0018→0025. Its current source now bounds retained body bytes and receive-event work independently, and also validates the ASGI callable→awaitable boundary. RED 755740cdecb0f13187ecd2ca20bc1e961ec6d7e5 proves a synchronous receive result otherwise leaks raw TypeError; repair 52a2fa0e6f2910e09d689d1985f8955db9b53e2e fails closed before event validation while preserving exceptions/cancellation raised inside valid awaitables.

Keep #435 open. The stack still lacks canonical same-tree #260 package / #311 PostgreSQL execution, the #437 typed expiry-vs-integrity repair, architecture source currentization/admission, released Keyverse/Orgmetra positive authority, actual authenticated scope + receive + send owner dispatch, response/send-closed/connection cleanup, snapshot lifecycle, deployment/fault/recovery evidence and full buyer-path p95 acceptance. Source/test currentization is not protected or release evidence.

Current durable/product-composition owner path is #436 30d89fa8... → #437 a09d6fb9... → #438 6cd7a908... → #439 dbee7dcd... → #440 0050f147... → #442 9bbb792e... → #443 728f07a8... → #444 e1af671deeeec682dffdf809cb8579dcc4d439da → #446 7954f5bf606584ddb5bbcd29e1b64e49041b9409. The inherited receive/currentness repairs remain adopted ordinary-forward; no force-push or destructive rebase was used.

#437 remains durable currentness owner and keeps ServingEvidenceExpiredError separate from ActivationAuthorizationError integrity/security failures. #443 remains inbound request-body lifecycle authority. #444 remains core response-event/send primitive authority and preserves closed-connection/runtime failures. #446 adds complete-response authority above it: whole-response prevalidation before start, terminal completion, explicit HEAD plus 204/205/304 no-content semantics, explicit Content-Length consistency, ASGI protocol-server ownership of transfer coding, and detachment of caller-owned mutable header pairs before the first transport await.

The latest #446 delta is review-quality repair rather than product semantics. d4ef66367cb369a29039dc80cef22b9821077c59 fixes the valid RUF043 regex finding. 46d6d98a108cec5777ba8634e1db50ce56cc1b8b → 6cb776f0182fb8a012ceff0f94809016e0533e8a → current 7954f5bf606584ddb5bbcd29e1b64e49041b9409 documents all nested helpers in the three changed tests after CodeRabbit reported only 58.54% diff-scoped docstring coverage across 41 functions. The inline finding is resolved. Current-head re-review is transiently rate-limited, so no review/runtime GREEN is inferred.

No SQL/migration byte or durable HR authority changed; lineage remains 0018→0025. Keep #435 open. Canonical same-tree #260 package / #311 PostgreSQL execution, architecture source currentization/admission, immutable released Keyverse/Orgmetra positive authority, an authenticated scope + receive + send host with owner dispatch and success-response/GET-backed HEAD semantics, scope-aware extension/trailer negotiation if needed, connection/pool cleanup, snapshot reload/invalidation, deployment/fault/recovery evidence and full buyer-path p95 acceptance remain open. Source typing, standards alignment, review repair and clean stacking are not protected or release evidence.

Navigation Menu

Repository navigation

product/composition: persist immutable generation and activation authority #435

Buyer-visible gap

Dependency boundary

Durable invariants

Implementation order

Acceptance

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

product/composition: persist immutable generation and activation authority #435

Description

Buyer-visible gap

Dependency boundary

Durable invariants

Implementation order

Acceptance

Activity

seonghobae commented on Sep 21, 2026

seonghobae commented on Sep 22, 2026

seonghobae commented on Sep 22, 2026

seonghobae commented on Sep 22, 2026

seonghobae commented on Sep 22, 2026

seonghobae commented on Sep 22, 2026

seonghobae commented on Sep 22, 2026

seonghobae commented on Sep 22, 2026

seonghobae commented on Sep 22, 2026

seonghobae commented on Sep 22, 2026

seonghobae commented on Sep 22, 2026

seonghobae commented on Sep 22, 2026

seonghobae commented on Sep 22, 2026

seonghobae commented on Sep 22, 2026

seonghobae commented on Sep 22, 2026

seonghobae commented on Sep 22, 2026

seonghobae commented on Sep 22, 2026

seonghobae commented on Sep 22, 2026

seonghobae commented on Sep 22, 2026

seonghobae commented on Sep 22, 2026

seonghobae commented on Sep 22, 2026

seonghobae commented on Sep 22, 2026

seonghobae commented on Sep 23, 2026

seonghobae commented on Sep 23, 2026

seonghobae commented on Sep 23, 2026

seonghobae commented on Sep 23, 2026

seonghobae commented on Sep 24, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions