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

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

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: engineering-process
-Version: 0.7.0
+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
@@ -600,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
@@ -608,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:
@@ -686,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,
@@ -717,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,
@@ -747,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

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

@@ -164,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
@@ -177,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.7.0 → 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
@@ -565,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
@@ -573,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:
@@ -651,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,
@@ -682,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,
@@ -712,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

{engineering_process-0.7.0 → engineering_process-0.8.0}/VERSIONING.md

@@ -118,6 +118,49 @@ base, so a base advance forces a new head and invalidates the old completion che
 The producer capability must be released immutably before a consumer pins and enables
 it; no consumer may depend on the producer working tree.
 
+## Process-adoption proposal capability
+
+Automation-proposal schema 3 is a separate `process-adoption` contract. The consumer
+must first merge a completed opt-in policy that fixes Renovate as the proposal owner,
+fixes an immutable protected-base verifier repository and commit, requires
+`consumer-owner-merge`, and structurally sets `automerge` false,
+`consumerOwnerMergeRequired` true, and `postMergeMutation` false. Schema 1 and schema
+2 dependency proposals retain their released fields and completion routes.
+
+The protected-base policy fixes both producer and verifier repositories. The verifier
+binds one complete candidate to the immutable producer release, tag,
+commit and attestation; source and target authority identities; exact requirements
+input and complete hash lock bytes; target process lock; complete selected managed
+distribution; declared project migration; grouped full-SHA action-pin replacements;
+and exact repository, protected base, head, path set, metadata and verifier identity.
+The actual protected base is supplied independently of Renovate evidence. The report
+binds bounded raw release-contract and distribution-attestation bytes, the lifecycle
+receipt identity, complete artifact hashes, and exact target materialization. Those
+report-controlled bytes grant no authority alone. The protected-base adapter supplies
+a separate clean exact-tag producer checkout, release artifacts, receipt, and
+attestation; existing release/attestation validators resolve tag ancestry, receipt,
+artifact bytes, process digest, and complete consumer synchronization. The
+independently resolved base must be an ancestor of the head;
+every producer action use in the bounded regular-workflow tree must move as one group
+with unchanged mode, and the verified wheel hash must occur in the lock. Missing or
+stale identity, a partial pin, an omitted lock or managed file, an inferred migration,
+an unrelated workflow/path change, or a post-merge action fails closed before
+candidate-owned project commands run.
+
+Renovate creates this complete PR before consumer-owner review and never merges it.
+The consumer owns its project migration, commands, checks, review choice and merge
+decision. Manual consumer-owner merge is the terminal adoption cutover; neither
+proposal validation, lifecycle completion, standing automation nor provider state can
+escalate it to automatic merge, and no synchronization follows merge. This boundary
+does not affect an agent-host PR created only after full lifecycle completion: that
+exact head retains standing-policy auto-merge.
+
+The producer ships and self-adopts this capability before any repository enables
+schema 3 or before Renovate operations allow its exact post-upgrade command. Capability
+release, consumer opt-in and Renovate operations activation are separate reviewed
+changes; same-release activation and dependence on a producer working tree are
+forbidden.
+
 ## Federated process-improvement capability
 
 Improvement signals, dispositions, resolutions, reproductions, and the producer
@@ -191,25 +234,31 @@ process semantics.
 
 ## Release and adoption boundary
 
-Release, self-adoption, and consumer adoption are separate changes:
+Release, self-adoption, and consumer adoption are separate changes. The numbered
+sequence below is the default agent-host completion-first route:
 
 1. Release N governs and verifies the source of N+1.
 2. N+1 is published as an immutable release and its public hashes are verified.
 3. Consumer-owned automation prepares an unpublished local candidate artifact,
    updates the direct pin, regenerates the hash-locked dependency graph, and runs the
-   managed adoption runner. Renovate must not publish a process-authority branch or
-   PR because its normal PR-first execution cannot satisfy this lifecycle boundary.
+   managed adoption runner. On this agent-host route, no process-authority branch or
+   PR is published before lifecycle completion.
 4. Required profiles validate the immutable candidate. The consumer-selected host
    supplies an independent semantic agent or human review; findings repeat candidate
    generation and full verification until lifecycle completion. Each
    platform/runtime job publishes a bounded supplemental evidence bundle bound to the
    source checkpoint, workflow checkpoint, run identity, and profile-report hashes.
-   Only after completion may automation push the candidate branch and create the PR
+   Only after completion may the agent host push the candidate branch and create the PR
    containing the process lock and every selected managed asset. A valid consumer
    standing policy may merge that exact checkpoint automatically after required
    checks; there is no post-merge synchronization.
 5. N+1 governs only changes that begin after the merged adoption checkpoint.
 
+An opted-in schema-3 Renovate `process-adoption` proposal is the explicit exception to
+steps 3-4: after complete materialization and protected-base proposal validation,
+Renovate may publish it before consumer-owner review. It never receives agent-host
+completion or standing auto-merge authority; consumer-owner manual merge is terminal.
+
 The repository-root GitHub Action and Python package are two surfaces of the same
 governed release checkpoint. A consumer invocation pins the action by the release
 commit's full object id and keeps the `v<SemVer>` annotation; Renovate groups that
@@ -224,13 +273,12 @@ and managed bootstrap snapshots required before a target version is installed. A
 clean-cutover PR may delete an obsolete local helper only after it pins an immutable
 public action checkpoint; no compatibility shim or dual execution path is retained.
 
-Process-authority adoption candidates are not controlled dependency proposals and
-cannot use that exception. PR creation is blocked until the adoption candidate has
-current completion evidence.
-Provider automerge before completion is forbidden for process-authority updates. A
-completed exact adoption candidate may merge automatically only under the consumer's
-standing policy. A PR that changes only a requirement pin, omits generated hashes or
-managed assets, or requires a post-merge step must fail closed.
+Process-authority adoption is not a controlled dependency proposal. An opted-in
+schema-3 consumer may receive a complete Renovate `process-adoption` PR before review,
+but it is permanently excluded from provider automerge. A separate agent-host
+candidate created after exact lifecycle completion remains on the standing-policy
+auto-merge route. A PR that changes only a requirement pin, omits generated hashes or
+managed assets, or requires a post-merge step fails closed on either route.
 
 `requirements/process.in` owns the direct public pin and `requirements/process.txt`
 is its pip-compile hash lock. The lock generator is pinned, and the committed lock must
@@ -281,9 +329,10 @@ falling back to a partial proposal.
   derived identity surface without writing protected `main` directly.
 - `processctl` derives and validates classification, compatibility, identity, reviewed
   tree equivalence, and authorization evidence.
-- Consumer automation may prepare complete unpublished adoption candidates before
-  completion; the lifecycle host publishes and, under standing policy, merges them
-  only after exact completion and protected checks.
+- Renovate may publish a complete schema-3 process-adoption proposal before owner
+  review, but only the consumer owner may merge it and merge is terminal. Agent-host
+  candidates published after exact lifecycle completion retain standing-policy
+  auto-merge.
 - Independent review verifies the exact Release PR classification, migration,
   verification, and evidence checkpoint.
 - The repository's standing policy authorizes the exact completed Release PR and each

{engineering_process-0.7.0 → engineering_process-0.8.0}/engineering_process/__init__.py

@@ -1,3 +1,3 @@
 """Agent-neutral engineering process."""
 
-VERSION = "0.7.0"
+VERSION = "0.8.0"

{engineering_process-0.7.0 → engineering_process-0.8.0}/engineering_process/bundles.py

@@ -20,7 +20,12 @@ def bundles_path(process_root: Path) -> Path:
     raise ContractError(f"{process_root}: cannot locate bundles.json")
 
 
-def load_bundles(process_root: Path, skills_root: Path) -> dict[str, tuple[str, ...]]:
+def load_bundles(
+    process_root: Path,
+    skills_root: Path,
+    *,
+    selected_skills: tuple[str, ...] | None = None,
+) -> dict[str, tuple[str, ...]]:
     path = bundles_path(process_root)
     document = read_json(path)
     if (
@@ -32,7 +37,16 @@ def load_bundles(process_root: Path, skills_root: Path) -> dict[str, tuple[str,
     ):
         raise ContractError(f"{path}: invalid bundle contract")
 
-    available = {directory.name for directory in skill_directories(skills_root)}
+    available = (
+        {directory.name for directory in skill_directories(skills_root)}
+        if selected_skills is None
+        else {
+            skill
+            for skill in selected_skills
+            if (skills_root / skill / "SKILL.md").is_file()
+            and not (skills_root / skill).is_symlink()
+        }
+    )
     result: dict[str, tuple[str, ...]] = {}
     owned: dict[str, str] = {}
     for name, raw_skills in document["bundles"].items():
@@ -48,7 +62,11 @@ def load_bundles(process_root: Path, skills_root: Path) -> dict[str, tuple[str,
             or raw_skills != sorted(set(raw_skills))
         ):
             raise ContractError(f"{path}: bundle {name} must be a sorted unique skill list")
-        missing = sorted(set(raw_skills) - available)
+        missing = sorted(
+            (set(raw_skills) - available)
+            if selected_skills is None
+            else (set(raw_skills) & set(selected_skills)) - available
+        )
         if missing:
             raise ContractError(
                 f"{path}: bundle {name} references missing skills: {', '.join(missing)}"

{engineering_process-0.7.0 → engineering_process-0.8.0}/engineering_process/cli.py

@@ -1341,8 +1341,34 @@ def _proposal_policy_evidence(args: argparse.Namespace):
     )
 
 
+def _proposal_producer_inputs(
+    args: argparse.Namespace, proposal: object
+) -> dict[str, Path] | None:
+    values = {
+        "root": args.producer_root,
+        "artifacts": args.producer_artifact_root,
+        "receipt": args.producer_receipt,
+        "attestation": args.producer_attestation,
+    }
+    supplied = [value is not None for value in values.values()]
+    if getattr(proposal, "proposal_kind", "dependency-update") == "process-adoption":
+        if not all(supplied):
+            raise ContractError(
+                "process-adoption validation requires --producer-root, "
+                "--producer-artifact-root, --producer-receipt, and "
+                "--producer-attestation"
+            )
+        return {name: value for name, value in values.items() if value is not None}
+    if any(supplied):
+        raise ContractError(
+            "producer release inputs apply only to process-adoption proposals"
+        )
+    return None
+
+
 def command_publication_validate_proposal(args: argparse.Namespace) -> int:
     proposal = _proposal_policy_evidence(args)
+    producer_inputs = _proposal_producer_inputs(args, proposal)
     source = source_state(args.project_root)
     issues = validate_controlled_automation_proposal(
         args.project_root,
@@ -1358,6 +1384,7 @@ def command_publication_validate_proposal(args: argparse.Namespace) -> int:
         verifier_commit=args.verifier_commit,
         proposal=proposal,
         source=source,
+        producer_inputs=producer_inputs,
     )
     return _publication_result(
         args,
@@ -1368,6 +1395,7 @@ def command_publication_validate_proposal(args: argparse.Namespace) -> int:
         branch=args.branch,
         commit=args.commit,
         completionCheck=proposal.completion_check,
+        consumerOwnerMergeRequired=proposal.consumer_owner_merge_required,
         proposalKind=proposal.proposal_kind,
         policySha256=proposal.opt_in_sha256,
         repository=args.repository,
@@ -1382,6 +1410,7 @@ def command_publication_validate_proposal_completion(
     args: argparse.Namespace,
 ) -> int:
     proposal = _proposal_policy_evidence(args)
+    producer_inputs = _proposal_producer_inputs(args, proposal)
     evidence = validate_receipt(args.evidence)
     project_path = args.project_root / ".process" / "project.json"
     project = validate_project(read_json(project_path), str(project_path))
@@ -1402,6 +1431,7 @@ def command_publication_validate_proposal_completion(
         proposal=proposal,
         evidence=evidence,
         source=source,
+        producer_inputs=producer_inputs,
     )
     return _publication_result(
         args,
@@ -1412,6 +1442,7 @@ def command_publication_validate_proposal_completion(
         changeId=evidence["changeId"],
         commit=args.commit,
         completionCheck=proposal.completion_check,
+        consumerOwnerMergeRequired=proposal.consumer_owner_merge_required,
         evidenceKind=args.evidence_kind,
         evidenceSha256=evidence["sha256"],
         policySha256=proposal.opt_in_sha256,
@@ -2026,6 +2057,10 @@ def build_parser() -> argparse.ArgumentParser:
     publication_proposal.add_argument("--body-file", type=Path)
     publication_proposal.add_argument("--verifier-repository", required=True)
     publication_proposal.add_argument("--verifier-commit", required=True)
+    publication_proposal.add_argument("--producer-root", type=Path)
+    publication_proposal.add_argument("--producer-artifact-root", type=Path)
+    publication_proposal.add_argument("--producer-receipt", type=Path)
+    publication_proposal.add_argument("--producer-attestation", type=Path)
     _add_json(publication_proposal)
     publication_proposal.set_defaults(
         handler=command_publication_validate_proposal
@@ -2058,6 +2093,14 @@ def build_parser() -> argparse.ArgumentParser:
         "--verifier-repository", required=True
     )
     publication_proposal_completion.add_argument("--verifier-commit", required=True)
+    publication_proposal_completion.add_argument("--producer-root", type=Path)
+    publication_proposal_completion.add_argument(
+        "--producer-artifact-root", type=Path
+    )
+    publication_proposal_completion.add_argument("--producer-receipt", type=Path)
+    publication_proposal_completion.add_argument(
+        "--producer-attestation", type=Path
+    )
     _add_json(publication_proposal_completion)
     publication_proposal_completion.set_defaults(
         handler=command_publication_validate_proposal_completion