engineering-process 0.7.0__tar.gz → 0.9.0__tar.gz

{engineering_process-0.7.0/engineering_process.egg-info → engineering_process-0.9.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: engineering-process
-Version: 0.7.0
+Version: 0.9.0
 Summary: Agent-neutral end-to-end engineering lifecycle and deterministic process CLI
 License-Expression: MIT
 Project-URL: Homepage, https://github.com/phuongnse/engineering-process
@@ -19,6 +19,7 @@ Description-Content-Type: text/markdown
 License-File: LICENSE
 Requires-Dist: markdown-it-py==4.2.0
 Requires-Dist: mdurl==0.1.2
+Requires-Dist: pyyaml==6.0.3
 Requires-Dist: regex==2026.7.19
 Provides-Extra: dev
 Requires-Dist: attrs==26.1.0; extra == "dev"
@@ -175,17 +176,18 @@ Renovate must install and verify a target authority before that target exists in
 checkout, and `processctl sync --check` compares those bytes with the pinned
 distribution.
 
-For an existing consumer, automation may prepare one unpublished adoption candidate,
-but the normal Renovate PR-first route is excluded from process-authority updates.
-The managed runner installs the target authority from the complete hash lock outside
-the checkout and atomically updates the process lock and managed assets before the
-lifecycle host publishes the completed candidate. If the consumer chooses or requires
-new project configuration, it adds
+For an existing opted-in consumer, Renovate may prepare and publish one complete
+process-adoption proposal before consumer-owner review. The managed runner installs
+the target authority from the complete hash lock outside the checkout and atomically
+updates the process lock and managed assets before PR creation. If the consumer
+chooses or requires new project configuration, it adds
 `.process/adoption-migrations/<target-version>.json`; the installed target authority
 binds the source and target manifest digests, validates the complete target manifest,
 and updates `.process/project.json` in the same rollback transaction. Optional
-capabilities are never inferred. CI and a fresh isolated review context approve the
-fully materialized checkpoint; merge completes adoption and no post-merge sync runs.
+capabilities are never inferred. Consumer CI and its chosen review approve the fully
+materialized checkpoint. Renovate cannot auto-merge it; consumer-owner merge completes
+adoption and no post-merge sync runs. Separately, an agent-host candidate created only
+after lifecycle completion retains normal standing-policy auto-merge.
 
 The engineering-process producer repository separately owns its root
 `.gitattributes` policy so tracked text sources and distribution inputs are LF and
@@ -462,8 +464,13 @@ processctl change review submit --change-id issue-123 --report review.json
 ~~~
 
 `changes-requested` returns to `change implement`, which starts a new cycle and
-invalidates prior verification and approval. `approved` can advance only while the
-source still matches:
+invalidates prior verification and approval. Under the bounded-loop authority this
+is finite: the third changes-requested final-review cycle in one decision window
+records an owner-decision escalation and blocks a fourth autonomous implementation
+cycle. Finding renames, splits, paths, severities and invariant labels do not reset
+the count. The existing decision-required assessment, challenged recommendation and
+owner resolution may open one fresh three-cycle window; they never approve or remove
+findings. `approved` can advance only while the source still matches:
 
 ~~~text
 processctl change finish --change-id issue-123 \
@@ -471,6 +478,43 @@ processctl change finish --change-id issue-123 \
 processctl change status --change-id issue-123
 ~~~
 
+### Process authority transition
+
+A trust-root adoption uses a clean N-1 control checkout and a separate N+1 candidate
+checkout. Register the exact transition before the target changes any candidate file,
+then let the installed target emit only non-authoritative evidence:
+
+~~~text
+processctl change transition register --project-root control \
+  --change-id adopt-process-0-9-0 --request transition-request.json \
+  --target-checkout target-tag-checkout --artifact-root target-artifacts \
+  --release-receipt target-evidence.json --artifact-attestation target-artifacts.json \
+  --actor worker --context worker-session --actor-kind agent
+
+processctl authority-transition candidate-evidence \
+  --candidate-root candidate --target-process-root /installed/target \
+  --request transition-request.json --output candidate-evidence.json \
+  --actor candidate-materializer --context candidate-session --actor-kind agent
+
+processctl change transition ingest --project-root control \
+  --change-id adopt-process-0-9-0 --candidate-root candidate \
+  --target-process-root /installed/target --evidence candidate-evidence.json \
+  --actor worker --context worker-session --actor-kind agent
+~~~
+
+Every later `change verify`, `change remote`, `change review`, `change finish`, and
+`change status` command supplies the same `--candidate-root`; lifecycle state and the
+CLI authority remain in `control`. The target lock never becomes an ordinary bypass.
+Transition verification, review, completion, remote evidence and receipt use their
+transition-only schema majors.
+
+The initial producer bootstrap is separate. Public 0.7.0 completes an exact intent
+and protected-transition policy. A verifier checked out from the policy's fixed
+protected-base feature commit validates the 0.7.0 bundle, immutable target release,
+complete candidate and current base. Only its fixed
+`authority-transition-completion` check may feed the policy-bound exact-head merge;
+the successful merge consumes the authorization and activates the target.
+
 One worker owning specification, planning, implementation, and verification is the
 default topology. Bounded helpers are optional optimizations, not required roles;
 only review requires a separate actor and context.
@@ -578,7 +622,22 @@ drift repeats the assessment with a newly reserved reviewer context bound to the
 source checkpoint. Earlier assignment, assessment, and owner-decision artifacts stay
 historical and cannot authorize the new cycle.
 
-When a schema-3 change selects a project-owned `requiredEvidence` id, local profiles
+New finite-boundary changes use change schema 4. Their `reviewBoundary` is a closed
+set of trust boundaries and fault rows; every row names its trigger or injection
+boundary, expected outcome, criteria, proving profiles/evidence, and stop condition.
+Every review finding is exactly `covered` or `contract-gap`. Covered findings bind
+one declared row and carry that identity unchanged. Contract gaps bind no row, remain
+open, and trigger owner decision on the first review. The registered contract is
+never extended in place: after owner decision the current lifecycle stays
+superseded, and a new contract must explicitly own the expanded boundary.
+
+Review-loop decision windows start prospectively under the adopted authority; older
+lifecycle artifacts are not replayed into a new counter. Resolved escalation chains
+are retained separately from the mutable current plan-decision slot and are included
+in completion and exported receipt evidence. This reuses existing reviewers and
+recommendation authority; it adds no loop arbiter or reviewer-of-reviewer.
+
+When a schema-3 or schema-4 change selects a project-owned `requiredEvidence` id, local profiles
 alone do not advance it to review. Create the exact no-authority request, run the
 project adapter, and ingest the complete supplemental set first:
 
@@ -600,7 +659,7 @@ to the explicit durable failure location before cleanup. Remote artifacts and th
 service ids remain lifecycle evidence, not merge, release, deployment, or adoption
 authority.
 
-The canonical publication order is stricter than a PR-first workflow: implementation
+The default agent-host publication order is stricter than a PR-first workflow: implementation
 and every required local and remote profile pass on a clean checkpoint; a consumer-selected independent
 agent or human semantically reviews that checkpoint; findings repeat implementation,
 complete verification, and fresh review until approved; `change finish` records
@@ -608,6 +667,9 @@ completion; only then may automation push and create the PR. Static policy/secre
 checks supplement this review and cannot generate a semantic verdict. With a valid
 standing policy, automation then waits for exact-head/current-base required checks and
 performs the configured merge without a separate human step.
+An opted-in schema-3 Renovate process-adoption proposal is the explicit pre-review
+publication exception; its complete candidate passes protected-base proposal
+validation first, then consumer-owner review and manual terminal merge.
 
 Completed local evidence can be moved across machines or attached to a release as a
 bounded receipt. Export and validate it before any explicit prune:
@@ -686,13 +748,14 @@ without per-action confirmation.
 ### Controlled automation proposals
 
 Completion-before-publication remains the default. A consumer may enable an untrusted
-dependency proposal before completion only through a policy file already present on
-the protected base at `.process/automation-proposals.json`. The policy uses the
-shape in `examples/automation-proposal-policy.json`: current policy uses schema 2,
-selects the target and automation prefix, allows only `dependency-update`,
-requires the canonical `lifecycle-completion` check, and fixes every dangerous control
-to its fail-closed value. Absence, disablement, a branch-only policy, or a policy digest
-mismatch blocks the route.
+automation proposal before completion only through a policy file already present on
+the protected base at `.process/automation-proposals.json`. Schema 1 and schema 2 use
+the shape in `examples/automation-proposal-policy.json`, allow only
+`dependency-update`, require the canonical `lifecycle-completion` check, and retain
+their released human-only and completion-gated meanings. Schema 3 uses
+`examples/automation-process-adoption-policy.json` for the distinct
+`process-adoption` route. Absence, disablement, a branch-only policy, or a policy
+digest mismatch blocks every route.
 
 The immutable provider verifier emits one bounded
 `engineering-process-controlled-automation-proposal` report for the exact repository,
@@ -717,9 +780,9 @@ processctl publication validate-proposal --project-root . \
 
 This pass proves only that the proposal is safe to expose as untrusted input. It is
 not verification, semantic review, completion, or merge authority. Proposal checks
-remain read-only and receive no secrets; automerge, scripts, plugins, shell execution,
-privileged CI, process-authority, workflow, release, deployment, security-policy, and
-trust-root changes are excluded.
+remain read-only and receive no secrets. Dependency proposals exclude automerge,
+scripts, plugins, shell execution, privileged CI, process-authority, workflow,
+release, deployment, security-policy, and trust-root changes.
 
 The required completion check is absent on every new proposal head. After the exact
 head completes the lifecycle, export its receipt, finalize the managed PR requirements,
@@ -747,6 +810,53 @@ after the protected base's standing automation policy and exact completion gate
 Provider tokens, check APIs, branch protection, retries, and repository selection
 remain consumer-owned adapter behavior.
 
+Schema-3 process adoption has a different merge boundary. Renovate may create the PR
+only after its allowlisted managed runner has materialized the complete target: direct
+pin, cross-platform hash lock, process lock, managed files, any declared project
+migration, and every immutable action pin. A protected-base immutable verifier is
+fixed by repository and commit in the opt-in policy. Its evidence binds the producer
+release/tag/commit/attestation, source and target authority versions and digests,
+requirements bytes, exact base/head/path set, migration result, complete managed-file
+set, and exact verifier identity. Workflow changes must be only the declared full-SHA
+action-pin replacements with their release annotations.
+
+The protected-base policy also fixes the producer repository. The report binds bounded
+raw release-contract and distribution-attestation bytes, their digests, lifecycle
+receipt identity, complete artifact hashes, and the verifier's exact target
+materialization result. The adapter independently supplies a clean producer checkout
+with the exact tag and origin plus downloaded release artifacts, lifecycle receipt,
+and attestation; report bytes alone never pass. Existing release and
+artifact-attestation validators resolve those objects before the target distribution
+is compared with the complete consumer materialization. Validation also requires the
+target wheel hash in the committed requirements lock and every use of that producer action
+across the complete regular-workflow tree; the protected base must be an ancestor and
+workflow mode may not change. Workflow semantics are read with the pinned maintained
+PyYAML safe loader; the process does not maintain a substitute YAML scanner.
+
+For schema 3, add these independently resolved inputs to `validate-proposal`:
+
+~~~text
+  --producer-root <clean-release-checkout> \
+  --producer-artifact-root <downloaded-release-artifacts> \
+  --producer-receipt <release-lifecycle-receipt> \
+  --producer-attestation <distribution-attestation>
+~~~
+
+The schema fixes `automerge` to false, `consumerOwnerMergeRequired` to true, and
+`postMergeMutation` to false. `publication validate-proposal-completion` always rejects
+this kind: lifecycle completion, standing automation, provider state, and a successful
+proposal check cannot convert it to automatic merge. The consumer chooses project
+configuration, commands, verification, review method, and whether to merge. Its owner
+manually merges the reviewed PR; that merge is the terminal adoption cutover and no
+post-merge synchronization runs.
+
+This does not alter the ordinary agent-host route. When an agent host completes the
+full lifecycle before it creates a source or adoption PR, the completed exact head may
+still auto-merge under the protected base's standing policy. Origin and publication
+state select the route: an agent-host completed PR is not reclassified as a Renovate
+proposal, and a Renovate process-adoption proposal never inherits completed-source
+auto-merge authority.
+
 ## Trust boundary
 
 The CLI proves structural separation: reviewer actor id and context id must both be
@@ -771,10 +881,27 @@ carried findings; the attesting host or human boundary, not local process state,
 authenticates who produced it.
 
 The producer release workflows implement the same host-neutral chain with explicit
-artifacts and callbacks: `release-pr.yml` creates only an unpublished Git bundle;
-`release-candidate.yml` restores it and runs `change start`, `change plan`,
-`change implement`, and every required `change verify`; the resulting
-`engineering-process-review-required` event names the exact artifact and checkpoint.
+artifacts and callbacks: `release-pr.yml` creates only an unpublished Git bundle.
+For an ordinary governed Release, `release-candidate.yml` restores it and runs
+`change start`, `change plan`, `change implement`, and every required `change verify`;
+the resulting `engineering-process-review-required` event names the exact artifact
+and checkpoint. The one `authority-transition-bootstrap` Release instead contains an
+authored schema-3 plan readable by immutable public 0.7. The initial workflow runs
+`change start`, `change plan`, and `change decision start`, then emits
+`engineering-process-plan-review-required` without implementing the candidate. A
+fresh read-only plan reviewer returns the exact assigned report to
+`release-plan-approval.yml`; that protected-main callback authenticates the producing
+workflow path, protected-base SHA, run id and attempt before restoring the same source
+and lifecycle. The provider handoff carries the id and attempt together as the
+required `plannedRun` object so every identity remains explicit without exceeding
+GitHub's ten-property `client_payload` limit. A protected-base adapter renders and
+validates that bounded event before the provider call. It submits the report,
+implements, verifies, and emits the ordinary
+source-review handoff. A separate bounded `needs: continue`, `always()` cleanup job
+runs on another runner after primary-job success, failure, timeout, or interruption;
+after artifact resolution it preserves bounded diagnostics, consumes and reconciles
+the single-use planned artifact, and makes a retry require a fresh planned run and
+assignment. It cannot finish, publish, or merge the Release.
 The consumer-selected host restores that lifecycle, chooses an agent or human,
 registers the assignment, submits the exact report, resolves any finding loop, runs
 `change finish`, and exports completion evidence. It sends only that bounded

{engineering_process-0.7.0 → engineering_process-0.9.0}/PROCESS_IMPROVEMENT.md

@@ -97,6 +97,14 @@ with the same reusable class and `activeChangeId` as the selected lifecycle. Rel
 PR materialization resolves only entries whose active change is in the exact release
 change set.
 
+Repeated friction is also counted at the lifecycle boundary. Three
+changes-requested final-review cycles in one prospective decision window are one
+owner-escalation class even when findings are renamed, split, moved, or assigned new
+local invariant ids. Core blocks the next implementation cycle and preserves the
+complete chain. For a finite-boundary contract, an observed failure outside every
+declared row is a contract gap on its first review and requires a superseding change;
+it cannot be closed through another local-fix label.
+
 ## Release and adoption
 
 Producer completion, producer release, consumer adoption, and consumer reproduction

{engineering_process-0.7.0 → engineering_process-0.9.0}/PRODUCTION_STANDARD.md

@@ -143,6 +143,22 @@ evidence. Reviewer-of-reviewer, meta-assessment, assessment-of-assessment,
 policy-for-policy, dynamically generated approval chains, and generic workflow
 engines are outside the portable contract.
 
+Correction autonomy is finite. Under the adopted bounded-loop authority, three
+distinct final-review cycles with changes-requested in one decision window trigger a
+durable owner-decision escalation and block a fourth implementation cycle. Counting
+is independent of finding names, invariant labels, paths, severities and splits. The
+stop preserves every finding and failed quality assessment; it never creates
+approval. Recovery reuses the existing decision-required plan assessment,
+independently challenged recommendation and explicit owner resolution. A resolved
+covered-boundary decision opens one fresh window; a contract-gap decision supersedes
+the lifecycle and requires a new immutable contract.
+
+New finite-boundary contracts enumerate closed fault rows with trigger or injection
+boundary, expected outcome, criteria, proof and stop condition. Every finding is
+exactly covered by one row or is a contract gap. Review does not expand the model by
+inventing adjacent instruction-level injection points, and it never hides an observed
+gap as out of scope. Historical artifacts are not retroactively counted.
+
 A material owner decision derives recommendation eligibility before optimization.
 Every option assesses every governing hard invariant and references only proven or
 explicitly unproven assumptions. Any violated invariant makes the option invalid; any
@@ -164,6 +180,15 @@ release, deployment, or adoption authority.
 
 ## Resource and generated-state policy
 
+Before implementing a standard format, protocol, parser, serializer, cryptographic
+primitive, or platform integration, evaluate maintained dependencies and supported
+tools at the owning boundary. Prefer a mature dependency when it materially reduces
+custom semantics and satisfies compatibility, licensing, supply-chain, portability,
+and resource-bound requirements; add it through the project's managed dependency and
+lock flow. A custom implementation requires concrete evidence that available
+dependencies cannot meet the accepted contract. Do not recreate a mature standard
+merely to avoid proposing or installing a useful dependency.
+
 Every operation over repository-controlled or remote input has explicit limits for
 time, count, individual item size, aggregate size, output, and process descendants.
 Limits fail closed and have regression coverage for success, failure, timeout, and
@@ -177,6 +202,54 @@ authority, and shares one rollback boundary with the process lock and managed as
 Optional capabilities are never inferred, while configuration required by the target
 authority blocks adoption when it is missing or invalid.
 
+A self-hosted authority transition keeps the governing and candidate workspaces
+separate. N-1 owns lifecycle state and every authoritative decision; N+1 output is
+bounded untrusted input. The pre-registered request fixes source and target authority,
+release provenance, base, paths, migration, selected assets and expiry. Transition
+verification recomputes the clean candidate commit, tree, workspace, lock, hash graph,
+managed distribution and action-pin set. A protected-transition policy is a separate
+schema-1 mutation grant: it fixes the source-owned verifier commit, protected workflow,
+check context and App identity, exact current base and head, target, required checks, no post-merge
+mutation, and one-use protected auto-merge. Target or candidate code can never
+interpret the authorization that activates itself.
+
+Transition artifact schemas and portable contract validation share one serialized
+shape boundary. Operational entrypoints additionally enforce cross-field relations
+that standard JSON Schema cannot represent. Those semantic checks are mandatory at
+registration, evidence ingestion, protected validation and terminal consumption; a
+shape-only validation never grants authority. Candidate evidence includes observed
+apply/check/idempotence trees and an after-write rollback probe executed in disposable
+worktrees under a bounded target process.
+Repository identity comes from deterministic provider service evidence resolved by
+the existing project adapter: repository/release/tag/asset ids and URLs, immutable
+release state, peeled tag commit and artifact digests are pre-bound by canonical
+digest. Mutable local Git remote configuration is never repository provenance, and
+the provider adapter gains no acceptance authority.
+
+Proposal merge authority derives from proposal origin and publication state. An
+agent-host review object created only after full lifecycle completion may use standing
+policy auto-merge for its exact approved head. A Renovate `process-adoption` proposal
+is created before consumer-owner review and must instead fix automerge false,
+`consumerOwnerMergeRequired` true, and post-merge mutation false. Lifecycle
+completion, standing policy, provider state, and successful static checks never move
+that proposal onto the agent-host route. The consumer owns review and manually
+authorizes merge; merge is the terminal cutover.
+
+Before candidate-owned commands, a protected-base immutable verifier independently
+binds the actual base and exact head, producer release/tag/commit/attestation, source
+and target process identities, requirements bytes, process lock, migration result,
+complete selected managed-file set, grouped full-SHA action-pin-only workflow delta,
+and verifier identity. Producer and verifier repositories are protected-base owned;
+report-controlled release claims never authenticate themselves. A separately supplied
+clean tagged producer checkout, artifacts, receipt, and attestation pass the existing
+release/attestation validators and exact target synchronization. Base must be
+an ancestor of head, and every producer use in the regular-workflow tree moves as one
+unchanged-mode pin group. Partial, stale, inferred, unauthorized, or post-merge-dependent
+candidates fail closed. This portable boundary reuses ordinary Renovate generation,
+managed adoption, consumer CI, review and branch protection. It does not introduce a
+reviewer host, daemon, scheduler, generic workflow engine, dynamically generated
+approval chain, meta-assessment, or reviewer-of-reviewer layer.
+
 Released serialized contracts are never tightened in place. A new resource bound or
 meaning-changing requirement uses a new integer schema major with explicit migration;
 historical readers retain their published behavior. A new optional capability may

{engineering_process-0.7.0 → engineering_process-0.9.0}/README.md

@@ -140,17 +140,18 @@ Renovate must install and verify a target authority before that target exists in
 checkout, and `processctl sync --check` compares those bytes with the pinned
 distribution.
 
-For an existing consumer, automation may prepare one unpublished adoption candidate,
-but the normal Renovate PR-first route is excluded from process-authority updates.
-The managed runner installs the target authority from the complete hash lock outside
-the checkout and atomically updates the process lock and managed assets before the
-lifecycle host publishes the completed candidate. If the consumer chooses or requires
-new project configuration, it adds
+For an existing opted-in consumer, Renovate may prepare and publish one complete
+process-adoption proposal before consumer-owner review. The managed runner installs
+the target authority from the complete hash lock outside the checkout and atomically
+updates the process lock and managed assets before PR creation. If the consumer
+chooses or requires new project configuration, it adds
 `.process/adoption-migrations/<target-version>.json`; the installed target authority
 binds the source and target manifest digests, validates the complete target manifest,
 and updates `.process/project.json` in the same rollback transaction. Optional
-capabilities are never inferred. CI and a fresh isolated review context approve the
-fully materialized checkpoint; merge completes adoption and no post-merge sync runs.
+capabilities are never inferred. Consumer CI and its chosen review approve the fully
+materialized checkpoint. Renovate cannot auto-merge it; consumer-owner merge completes
+adoption and no post-merge sync runs. Separately, an agent-host candidate created only
+after lifecycle completion retains normal standing-policy auto-merge.
 
 The engineering-process producer repository separately owns its root
 `.gitattributes` policy so tracked text sources and distribution inputs are LF and
@@ -427,8 +428,13 @@ processctl change review submit --change-id issue-123 --report review.json
 ~~~
 
 `changes-requested` returns to `change implement`, which starts a new cycle and
-invalidates prior verification and approval. `approved` can advance only while the
-source still matches:
+invalidates prior verification and approval. Under the bounded-loop authority this
+is finite: the third changes-requested final-review cycle in one decision window
+records an owner-decision escalation and blocks a fourth autonomous implementation
+cycle. Finding renames, splits, paths, severities and invariant labels do not reset
+the count. The existing decision-required assessment, challenged recommendation and
+owner resolution may open one fresh three-cycle window; they never approve or remove
+findings. `approved` can advance only while the source still matches:
 
 ~~~text
 processctl change finish --change-id issue-123 \
@@ -436,6 +442,43 @@ processctl change finish --change-id issue-123 \
 processctl change status --change-id issue-123
 ~~~
 
+### Process authority transition
+
+A trust-root adoption uses a clean N-1 control checkout and a separate N+1 candidate
+checkout. Register the exact transition before the target changes any candidate file,
+then let the installed target emit only non-authoritative evidence:
+
+~~~text
+processctl change transition register --project-root control \
+  --change-id adopt-process-0-9-0 --request transition-request.json \
+  --target-checkout target-tag-checkout --artifact-root target-artifacts \
+  --release-receipt target-evidence.json --artifact-attestation target-artifacts.json \
+  --actor worker --context worker-session --actor-kind agent
+
+processctl authority-transition candidate-evidence \
+  --candidate-root candidate --target-process-root /installed/target \
+  --request transition-request.json --output candidate-evidence.json \
+  --actor candidate-materializer --context candidate-session --actor-kind agent
+
+processctl change transition ingest --project-root control \
+  --change-id adopt-process-0-9-0 --candidate-root candidate \
+  --target-process-root /installed/target --evidence candidate-evidence.json \
+  --actor worker --context worker-session --actor-kind agent
+~~~
+
+Every later `change verify`, `change remote`, `change review`, `change finish`, and
+`change status` command supplies the same `--candidate-root`; lifecycle state and the
+CLI authority remain in `control`. The target lock never becomes an ordinary bypass.
+Transition verification, review, completion, remote evidence and receipt use their
+transition-only schema majors.
+
+The initial producer bootstrap is separate. Public 0.7.0 completes an exact intent
+and protected-transition policy. A verifier checked out from the policy's fixed
+protected-base feature commit validates the 0.7.0 bundle, immutable target release,
+complete candidate and current base. Only its fixed
+`authority-transition-completion` check may feed the policy-bound exact-head merge;
+the successful merge consumes the authorization and activates the target.
+
 One worker owning specification, planning, implementation, and verification is the
 default topology. Bounded helpers are optional optimizations, not required roles;
 only review requires a separate actor and context.
@@ -543,7 +586,22 @@ drift repeats the assessment with a newly reserved reviewer context bound to the
 source checkpoint. Earlier assignment, assessment, and owner-decision artifacts stay
 historical and cannot authorize the new cycle.
 
-When a schema-3 change selects a project-owned `requiredEvidence` id, local profiles
+New finite-boundary changes use change schema 4. Their `reviewBoundary` is a closed
+set of trust boundaries and fault rows; every row names its trigger or injection
+boundary, expected outcome, criteria, proving profiles/evidence, and stop condition.
+Every review finding is exactly `covered` or `contract-gap`. Covered findings bind
+one declared row and carry that identity unchanged. Contract gaps bind no row, remain
+open, and trigger owner decision on the first review. The registered contract is
+never extended in place: after owner decision the current lifecycle stays
+superseded, and a new contract must explicitly own the expanded boundary.
+
+Review-loop decision windows start prospectively under the adopted authority; older
+lifecycle artifacts are not replayed into a new counter. Resolved escalation chains
+are retained separately from the mutable current plan-decision slot and are included
+in completion and exported receipt evidence. This reuses existing reviewers and
+recommendation authority; it adds no loop arbiter or reviewer-of-reviewer.
+
+When a schema-3 or schema-4 change selects a project-owned `requiredEvidence` id, local profiles
 alone do not advance it to review. Create the exact no-authority request, run the
 project adapter, and ingest the complete supplemental set first:
 
@@ -565,7 +623,7 @@ to the explicit durable failure location before cleanup. Remote artifacts and th
 service ids remain lifecycle evidence, not merge, release, deployment, or adoption
 authority.
 
-The canonical publication order is stricter than a PR-first workflow: implementation
+The default agent-host publication order is stricter than a PR-first workflow: implementation
 and every required local and remote profile pass on a clean checkpoint; a consumer-selected independent
 agent or human semantically reviews that checkpoint; findings repeat implementation,
 complete verification, and fresh review until approved; `change finish` records
@@ -573,6 +631,9 @@ completion; only then may automation push and create the PR. Static policy/secre
 checks supplement this review and cannot generate a semantic verdict. With a valid
 standing policy, automation then waits for exact-head/current-base required checks and
 performs the configured merge without a separate human step.
+An opted-in schema-3 Renovate process-adoption proposal is the explicit pre-review
+publication exception; its complete candidate passes protected-base proposal
+validation first, then consumer-owner review and manual terminal merge.
 
 Completed local evidence can be moved across machines or attached to a release as a
 bounded receipt. Export and validate it before any explicit prune:
@@ -651,13 +712,14 @@ without per-action confirmation.
 ### Controlled automation proposals
 
 Completion-before-publication remains the default. A consumer may enable an untrusted
-dependency proposal before completion only through a policy file already present on
-the protected base at `.process/automation-proposals.json`. The policy uses the
-shape in `examples/automation-proposal-policy.json`: current policy uses schema 2,
-selects the target and automation prefix, allows only `dependency-update`,
-requires the canonical `lifecycle-completion` check, and fixes every dangerous control
-to its fail-closed value. Absence, disablement, a branch-only policy, or a policy digest
-mismatch blocks the route.
+automation proposal before completion only through a policy file already present on
+the protected base at `.process/automation-proposals.json`. Schema 1 and schema 2 use
+the shape in `examples/automation-proposal-policy.json`, allow only
+`dependency-update`, require the canonical `lifecycle-completion` check, and retain
+their released human-only and completion-gated meanings. Schema 3 uses
+`examples/automation-process-adoption-policy.json` for the distinct
+`process-adoption` route. Absence, disablement, a branch-only policy, or a policy
+digest mismatch blocks every route.
 
 The immutable provider verifier emits one bounded
 `engineering-process-controlled-automation-proposal` report for the exact repository,
@@ -682,9 +744,9 @@ processctl publication validate-proposal --project-root . \
 
 This pass proves only that the proposal is safe to expose as untrusted input. It is
 not verification, semantic review, completion, or merge authority. Proposal checks
-remain read-only and receive no secrets; automerge, scripts, plugins, shell execution,
-privileged CI, process-authority, workflow, release, deployment, security-policy, and
-trust-root changes are excluded.
+remain read-only and receive no secrets. Dependency proposals exclude automerge,
+scripts, plugins, shell execution, privileged CI, process-authority, workflow,
+release, deployment, security-policy, and trust-root changes.
 
 The required completion check is absent on every new proposal head. After the exact
 head completes the lifecycle, export its receipt, finalize the managed PR requirements,
@@ -712,6 +774,53 @@ after the protected base's standing automation policy and exact completion gate
 Provider tokens, check APIs, branch protection, retries, and repository selection
 remain consumer-owned adapter behavior.
 
+Schema-3 process adoption has a different merge boundary. Renovate may create the PR
+only after its allowlisted managed runner has materialized the complete target: direct
+pin, cross-platform hash lock, process lock, managed files, any declared project
+migration, and every immutable action pin. A protected-base immutable verifier is
+fixed by repository and commit in the opt-in policy. Its evidence binds the producer
+release/tag/commit/attestation, source and target authority versions and digests,
+requirements bytes, exact base/head/path set, migration result, complete managed-file
+set, and exact verifier identity. Workflow changes must be only the declared full-SHA
+action-pin replacements with their release annotations.
+
+The protected-base policy also fixes the producer repository. The report binds bounded
+raw release-contract and distribution-attestation bytes, their digests, lifecycle
+receipt identity, complete artifact hashes, and the verifier's exact target
+materialization result. The adapter independently supplies a clean producer checkout
+with the exact tag and origin plus downloaded release artifacts, lifecycle receipt,
+and attestation; report bytes alone never pass. Existing release and
+artifact-attestation validators resolve those objects before the target distribution
+is compared with the complete consumer materialization. Validation also requires the
+target wheel hash in the committed requirements lock and every use of that producer action
+across the complete regular-workflow tree; the protected base must be an ancestor and
+workflow mode may not change. Workflow semantics are read with the pinned maintained
+PyYAML safe loader; the process does not maintain a substitute YAML scanner.
+
+For schema 3, add these independently resolved inputs to `validate-proposal`:
+
+~~~text
+  --producer-root <clean-release-checkout> \
+  --producer-artifact-root <downloaded-release-artifacts> \
+  --producer-receipt <release-lifecycle-receipt> \
+  --producer-attestation <distribution-attestation>
+~~~
+
+The schema fixes `automerge` to false, `consumerOwnerMergeRequired` to true, and
+`postMergeMutation` to false. `publication validate-proposal-completion` always rejects
+this kind: lifecycle completion, standing automation, provider state, and a successful
+proposal check cannot convert it to automatic merge. The consumer chooses project
+configuration, commands, verification, review method, and whether to merge. Its owner
+manually merges the reviewed PR; that merge is the terminal adoption cutover and no
+post-merge synchronization runs.
+
+This does not alter the ordinary agent-host route. When an agent host completes the
+full lifecycle before it creates a source or adoption PR, the completed exact head may
+still auto-merge under the protected base's standing policy. Origin and publication
+state select the route: an agent-host completed PR is not reclassified as a Renovate
+proposal, and a Renovate process-adoption proposal never inherits completed-source
+auto-merge authority.
+
 ## Trust boundary
 
 The CLI proves structural separation: reviewer actor id and context id must both be
@@ -736,10 +845,27 @@ carried findings; the attesting host or human boundary, not local process state,
 authenticates who produced it.
 
 The producer release workflows implement the same host-neutral chain with explicit
-artifacts and callbacks: `release-pr.yml` creates only an unpublished Git bundle;
-`release-candidate.yml` restores it and runs `change start`, `change plan`,
-`change implement`, and every required `change verify`; the resulting
-`engineering-process-review-required` event names the exact artifact and checkpoint.
+artifacts and callbacks: `release-pr.yml` creates only an unpublished Git bundle.
+For an ordinary governed Release, `release-candidate.yml` restores it and runs
+`change start`, `change plan`, `change implement`, and every required `change verify`;
+the resulting `engineering-process-review-required` event names the exact artifact
+and checkpoint. The one `authority-transition-bootstrap` Release instead contains an
+authored schema-3 plan readable by immutable public 0.7. The initial workflow runs
+`change start`, `change plan`, and `change decision start`, then emits
+`engineering-process-plan-review-required` without implementing the candidate. A
+fresh read-only plan reviewer returns the exact assigned report to
+`release-plan-approval.yml`; that protected-main callback authenticates the producing
+workflow path, protected-base SHA, run id and attempt before restoring the same source
+and lifecycle. The provider handoff carries the id and attempt together as the
+required `plannedRun` object so every identity remains explicit without exceeding
+GitHub's ten-property `client_payload` limit. A protected-base adapter renders and
+validates that bounded event before the provider call. It submits the report,
+implements, verifies, and emits the ordinary
+source-review handoff. A separate bounded `needs: continue`, `always()` cleanup job
+runs on another runner after primary-job success, failure, timeout, or interruption;
+after artifact resolution it preserves bounded diagnostics, consumes and reconciles
+the single-use planned artifact, and makes a retry require a fresh planned run and
+assignment. It cannot finish, publish, or merge the Release.
 The consumer-selected host restores that lifecycle, chooses an agent or human,
 registers the assignment, submits the exact report, resolves any finding loop, runs
 `change finish`, and exports completion evidence. It sends only that bounded