engineering-process 0.6.1__tar.gz → 0.8.0__tar.gz

{engineering_process-0.6.1/engineering_process.egg-info → engineering_process-0.8.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: engineering-process
-Version: 0.6.1
+Version: 0.8.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
@@ -536,6 +538,48 @@ resolution records a selected valid option but grants no lifecycle completion, m
 release, deployment, or adoption authority. Those owning gates remain separate. The
 accepted decision is recorded before dependent work resumes.
 
+Projects may separately adopt the `provenance-gated-authored-review` lifecycle policy.
+Under that policy, every new nontrivial authored plan uses schema 3 and is assessed
+before implementation by a genuinely fresh read-only reviewer. The assessment covers
+architecture, authority, compatibility, external mutation, lifecycle order, owner,
+rollout, scope, and trust boundary for the exact contract, plan, clean source,
+authority, policy, author, and reviewer context. A clear assessment permits
+implementation. A decision-required assessment must complete the existing reviewed
+recommendation and owner-resolution chain, with a dedicated invariant binding the
+exact assessment digest:
+
+~~~text
+processctl change decision start --project-root . --change-id issue-123 \
+  --actor <reviewer> --context <fresh-context> --actor-kind agent \
+  --method isolated-context --attested-by <host> \
+  --attestation-evidence <bounded-attestation>
+processctl contract validate --kind plan-decision-review \
+  plan-decision-review.json
+processctl change decision submit --project-root . --change-id issue-123 \
+  --review plan-decision-review.json
+processctl change decision resolve --project-root . --change-id issue-123 \
+  --actor <coordinator> --context <coordinator-context> --actor-kind agent \
+  --recommendation recommendation.json \
+  --assignment recommendation-review-assignment.json \
+  --recommendation-review recommendation-review.json \
+  --resolution recommendation-resolution.json
+processctl change implement --project-root . --change-id issue-123 \
+  --actor <worker> --context <worker-context> --actor-kind agent
+~~~
+
+The resolve command is used only for `decision-required`; a clear assessment goes
+directly to `change implement`. Unreviewed prose, risk tiers, heuristics, author
+self-classification, and generator labels are candidate-only and grant no authority.
+A generated bypass is valid only for a core-registered generator whose complete plan
+is exactly recomputed from bounded source-owned inputs and the immutable installed
+authority. Exact generated plans are not universally sent to semantic review. Core
+requires no daemon, scheduler, service, webhook receiver, hosted reviewer platform,
+vendor, model, or proprietary agent API.
+Every later implementation cycle after a finding or clean post-verification source
+drift repeats the assessment with a newly reserved reviewer context bound to the new
+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
 alone do not advance it to review. Create the exact no-authority request, run the
 project adapter, and ingest the complete supplemental set first:
@@ -558,7 +602,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
@@ -566,6 +610,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:
@@ -644,13 +691,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,
@@ -675,9 +723,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,
@@ -705,6 +753,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
@@ -791,9 +886,10 @@ fingerprint, source tree, or publication range.
   exclusively by their hash-locked `requirements/process.txt`. The action invokes the
   producer-owned installer from its immutable action checkout and never downloads or
   executes helper source from the consumer branch.
-- Versioned JSON schemas define change, plan, verification, review, recommendation,
-  independent recommendation assignment and challenge, owner resolution, lifecycle,
-  completion-related artifacts, release-change fragments, and the release
+- Versioned JSON schemas define change, plan provenance, plan-decision assignment and
+  review, verification, review, recommendation, independent recommendation assignment
+  and challenge, owner resolution, lifecycle, completion-related artifacts,
+  release-change fragments, and the release
   classification contract. The generated Release PR gate binds that contract to the
   exact SemVer increment, package version, latest reachable prior tag, reviewed head,
   identical merge tree, immutable checkpoint, and main ancestry.
@@ -806,10 +902,12 @@ fingerprint, source tree, or publication range.
   readable under their released semantics. GitHub's artifact id and digest complete
   the immutable remote reference; this supplements rather than replaces N-1
   lifecycle evidence.
-- New lifecycle work uses bounded plan schema 2. Selective-impact consumers may add
-  the optional capability on project schema 3, while new integrations use bounded
-  project schema 4. Plan schema 1 and the pre-existing fields of project schemas 1-3
-  retain their published validation behavior instead of being tightened in place.
+- Projects without plan-decision opt-in continue using bounded plan schema 2. An
+  opted-in project uses plan schema 3 provenance and the pre-implementation gate.
+  Selective-impact consumers may add optional capabilities on project schema 3,
+  while new integrations use bounded project schema 4. Plan schemas 1 and 2 and the
+  pre-existing fields of project schemas 1-3 retain their published validation
+  behavior instead of being tightened in place.
 - `release.json` is the single release-identity owner. Governed GitHub tag and title
   are both exactly `v<SemVer>`; package metadata, runtime version, artifact names,
   authorization evidence, and later consumer locks must match it. Public-impact PRs

{engineering_process-0.6.1 → engineering_process-0.8.0}/PRODUCTION_STANDARD.md

@@ -115,6 +115,34 @@ evidence boundaries as completion-blocking.
 
 ## Recommendation validity
 
+An opted-in project gates implementation through plan provenance. Every nontrivial
+authored plan receives a fresh read-only semantic assessment for architecture,
+authority, compatibility, external mutation, lifecycle order, owner, rollout, scope,
+and trust boundary. The assignment binds the exact contract, plan, clean source,
+authority, project policy, author, reviewer context, and canonical category set. A
+clear assessment may authorize implementation; a decision-required assessment must
+bind the existing independently reviewed recommendation and explicit owner resolution
+for that exact assessment. Drift in any binding fails closed.
+Each later implementation cycle after a finding or clean post-verification source
+drift requires a newly reserved context and assessment bound to that cycle's source;
+cycle-1 evidence cannot be relabeled or reused.
+
+A process-generated plan bypass is accepted only when the immutable installed core
+recognizes its generator and exactly recomputes the complete plan from bounded
+validated source-owned inputs. Generator labels, risk labels, author
+self-classification, heuristic prose scanning, and partial comparison are not
+provenance. Exact generated plans are not universally sent to semantic review, and
+portable core does not introduce a daemon, scheduler, webhook, hosted reviewer
+platform, vendor, model, or proprietary agent API. Unreviewed prose remains
+candidate-only and grants no decision or lifecycle authority.
+
+The three possible review boundaries never review one another. Plan-decision review
+assesses the authored plan; recommendation review challenges only the recommendation
+and its digest binding; final lifecycle review assesses implemented source and current
+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.
+
 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
@@ -136,6 +164,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
@@ -149,6 +186,30 @@ 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.
 
+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.6.1 → engineering_process-0.8.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
@@ -501,6 +502,48 @@ resolution records a selected valid option but grants no lifecycle completion, m
 release, deployment, or adoption authority. Those owning gates remain separate. The
 accepted decision is recorded before dependent work resumes.
 
+Projects may separately adopt the `provenance-gated-authored-review` lifecycle policy.
+Under that policy, every new nontrivial authored plan uses schema 3 and is assessed
+before implementation by a genuinely fresh read-only reviewer. The assessment covers
+architecture, authority, compatibility, external mutation, lifecycle order, owner,
+rollout, scope, and trust boundary for the exact contract, plan, clean source,
+authority, policy, author, and reviewer context. A clear assessment permits
+implementation. A decision-required assessment must complete the existing reviewed
+recommendation and owner-resolution chain, with a dedicated invariant binding the
+exact assessment digest:
+
+~~~text
+processctl change decision start --project-root . --change-id issue-123 \
+  --actor <reviewer> --context <fresh-context> --actor-kind agent \
+  --method isolated-context --attested-by <host> \
+  --attestation-evidence <bounded-attestation>
+processctl contract validate --kind plan-decision-review \
+  plan-decision-review.json
+processctl change decision submit --project-root . --change-id issue-123 \
+  --review plan-decision-review.json
+processctl change decision resolve --project-root . --change-id issue-123 \
+  --actor <coordinator> --context <coordinator-context> --actor-kind agent \
+  --recommendation recommendation.json \
+  --assignment recommendation-review-assignment.json \
+  --recommendation-review recommendation-review.json \
+  --resolution recommendation-resolution.json
+processctl change implement --project-root . --change-id issue-123 \
+  --actor <worker> --context <worker-context> --actor-kind agent
+~~~
+
+The resolve command is used only for `decision-required`; a clear assessment goes
+directly to `change implement`. Unreviewed prose, risk tiers, heuristics, author
+self-classification, and generator labels are candidate-only and grant no authority.
+A generated bypass is valid only for a core-registered generator whose complete plan
+is exactly recomputed from bounded source-owned inputs and the immutable installed
+authority. Exact generated plans are not universally sent to semantic review. Core
+requires no daemon, scheduler, service, webhook receiver, hosted reviewer platform,
+vendor, model, or proprietary agent API.
+Every later implementation cycle after a finding or clean post-verification source
+drift repeats the assessment with a newly reserved reviewer context bound to the new
+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
 alone do not advance it to review. Create the exact no-authority request, run the
 project adapter, and ingest the complete supplemental set first:
@@ -523,7 +566,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
@@ -531,6 +574,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:
@@ -609,13 +655,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,
@@ -640,9 +687,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,
@@ -670,6 +717,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
@@ -756,9 +850,10 @@ fingerprint, source tree, or publication range.
   exclusively by their hash-locked `requirements/process.txt`. The action invokes the
   producer-owned installer from its immutable action checkout and never downloads or
   executes helper source from the consumer branch.
-- Versioned JSON schemas define change, plan, verification, review, recommendation,
-  independent recommendation assignment and challenge, owner resolution, lifecycle,
-  completion-related artifacts, release-change fragments, and the release
+- Versioned JSON schemas define change, plan provenance, plan-decision assignment and
+  review, verification, review, recommendation, independent recommendation assignment
+  and challenge, owner resolution, lifecycle, completion-related artifacts,
+  release-change fragments, and the release
   classification contract. The generated Release PR gate binds that contract to the
   exact SemVer increment, package version, latest reachable prior tag, reviewed head,
   identical merge tree, immutable checkpoint, and main ancestry.
@@ -771,10 +866,12 @@ fingerprint, source tree, or publication range.
   readable under their released semantics. GitHub's artifact id and digest complete
   the immutable remote reference; this supplements rather than replaces N-1
   lifecycle evidence.
-- New lifecycle work uses bounded plan schema 2. Selective-impact consumers may add
-  the optional capability on project schema 3, while new integrations use bounded
-  project schema 4. Plan schema 1 and the pre-existing fields of project schemas 1-3
-  retain their published validation behavior instead of being tightened in place.
+- Projects without plan-decision opt-in continue using bounded plan schema 2. An
+  opted-in project uses plan schema 3 provenance and the pre-implementation gate.
+  Selective-impact consumers may add optional capabilities on project schema 3,
+  while new integrations use bounded project schema 4. Plan schemas 1 and 2 and the
+  pre-existing fields of project schemas 1-3 retain their published validation
+  behavior instead of being tightened in place.
 - `release.json` is the single release-identity owner. Governed GitHub tag and title
   are both exactly `v<SemVer>`; package metadata, runtime version, artifact names,
   authorization evidence, and later consumer locks must match it. Public-impact PRs