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

{engineering_process-0.8.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.8.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
@@ -464,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 \
@@ -473,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.
@@ -580,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:
 
@@ -824,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.8.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.8.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
@@ -186,6 +202,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.
 
+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

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

@@ -428,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 \
@@ -437,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.
@@ -544,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:
 
@@ -788,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

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

@@ -54,6 +54,17 @@ typed authorization bundle is not a lifecycle receipt. Self-adoption must pin th
 public version before another release can be prepared; every later release is
 `governed` by a receipt from its public N-1 authority.
 
+One producer-lineage exception exists for the immutable 0.7.0/0.8.0 authority
+deadlock. A release containing the permanent authority-transition protocol uses
+release schema 4 mode `authority-transition-bootstrap`. The source generator accepts
+that mode only while the producer lock is exactly 0.7.0, the latest public release is
+exactly 0.8.0, and the governed release set contains
+`authority-transition-protocol`. Public 0.7.0 supplies the lifecycle receipt and the
+source-owned verifier; 0.8.0 remains immutable public history but never becomes the
+producer authority. The version is still derived from the reviewed change set. After
+that one release is prepared, its new previous-version and source-lock predicates make
+a second use invalid.
+
 ## Serialized-contract versions
 
 Each artifact owns an independent integer `schemaVersion`. Package SemVer and schema
@@ -93,6 +104,15 @@ Package `schemaImpact` is `unchanged`, `additive`, or `breaking` for the combine
 release. Additive schema capability requires at least a capability release; a
 breaking schema requires an incompatible release.
 
+Authority transitions do not reinterpret the one-workspace artifacts already
+published. Transition-only generation uses release schema 4, distribution-attestation
+schema 2, lifecycle schema 3, verification schema 4, supplemental-verification schema
+3, review schema 4, completion schema 2, evidence-receipt schema 2, and remote request
+and evidence schema 2. Authority-transition request, candidate evidence,
+bootstrap-adoption intent, bootstrap consumption, and protected-transition policy
+start at schema 1. Every historical reader and generator retains its published
+meaning.
+
 ## Controlled dependency-proposal capability
 
 The strict default remains completion before any branch or PR publication. A consumer
@@ -232,6 +252,25 @@ matrix is not a compatibility substitute. Provider transport remains project-own
 while request expansion, ingestion, invalidation, and terminal ordering are portable
 process semantics.
 
+## Bounded review-correction authority
+
+Change schema 4 adds the finite review-boundary contract. Review, plan-decision
+assignment, lifecycle, completion, recommendation, and evidence-receipt schemas gain
+additive fields or references while preserving every released document's meaning.
+The adopted authority nevertheless changes workflow semantics: after three
+changes-requested final-review cycles, another implementation cycle is blocked until
+the existing reviewed owner-decision chain resolves it. Before 1.0 this is a breaking
+package change and therefore requires the next minor version, migration guidance,
+immutable publication, and separate self-adoption.
+
+Decision windows start prospectively. Historical states without `reviewLoop` remain
+unchanged and are never backfilled from old review events. New finite-boundary
+findings are either covered by one closed fault row or are contract gaps. Contract
+gaps keep their finding open and require a superseding change; no in-place extension
+or old evidence conversion is supported. Resolved loop decisions are retained in
+completion and receipt artifacts even after the mutable current plan assessment is
+refreshed.
+
 ## Release and adoption boundary
 
 Release, self-adoption, and consumer adoption are separate changes. The numbered
@@ -254,6 +293,30 @@ sequence below is the default agent-host completion-first route:
    checks; there is no post-merge synchronization.
 5. N+1 governs only changes that begin after the merged adoption checkpoint.
 
+For an explicit authority transition, steps 3-4 use two isolated workspaces. The
+control workspace stays clean, pinned, and synchronized to public N-1 and owns the
+lifecycle ledger. Before any candidate mutation, N-1 registers the exact source
+authority, target release provenance, control checkpoint, candidate base, selected
+assets, migration input, expected paths, and expiry. Installed N+1 may materialize
+and check only a separate candidate workspace and emit schema-1 evidence. N-1
+independently ingests that evidence, runs profiles against the exact candidate,
+assigns review, closes findings, completes, and publishes the candidate checkpoint.
+There is no `--ignore-lock` route and no lifecycle transition executed by N+1.
+
+The first producer cutover additionally uses a separately completed 0.7.0 bootstrap
+intent and a project-owner-installed protected-transition policy. The validated 0.7.0
+bootstrap bundle checkpoint Git-binds both artifacts. A verifier fixed to the exact
+0.7.0-governed protected-base feature commit runs outside target and candidate
+checkouts, resolves the target tag, receipt, attestation, artifacts and distribution,
+recomputes complete materialization, and compares the exact candidate. The policy
+fixes that verifier, workflow, check context, current base, target, exact head and
+protected auto-merge grant. Successful current-base merge is the atomic one-time
+consumption event; afterward the base and source lock no longer satisfy the policy.
+The tracked policy does not embed its own commit id. Instead the validated 0.7.0
+bundle supplies the reviewed checkpoint, and the adapter requires its Git tree to be
+byte-identical to the independently resolved current protected-base tree. This avoids
+a self-referential commit field while preserving an exact base binding.
+
 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

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

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

{engineering_process-0.8.0 → engineering_process-0.9.0}/engineering_process/adoption.py

@@ -775,6 +775,7 @@ def apply_adoption(
     *,
     requirements_source: Path | None = None,
     expected_requirements_digest: str | None = None,
+    rollback_probe: bool = False,
 ) -> dict[str, object]:
     project_root = Path(os.path.abspath(os.fspath(project_root)))
     process_root = process_root.resolve()
@@ -890,6 +891,10 @@ def apply_adoption(
                     project_root / ".process" / "project.json",
                     migration.target_content,
                 )
+            if rollback_probe:
+                raise ContractError(
+                    "controlled authority-transition rollback probe"
+                )
             issues = sync_skills(project_root, process_root, check=False)
             if issues:
                 raise ContractError("\n".join(issues))

{engineering_process-0.8.0 → engineering_process-0.9.0}/engineering_process/artifact_attestation.py

@@ -131,7 +131,10 @@ def _receipt_identity(
     *,
     checkpoint: str,
 ) -> dict[str, Any] | None:
-    if release.provenance_mode == "governed":
+    if release.provenance_mode in {
+        "governed",
+        "authority-transition-bootstrap",
+    }:
         if receipt_path is None:
             raise ContractError("governed artifact attestation requires a lifecycle receipt")
         if receipt_path.name != release.receipt_asset:
@@ -311,8 +314,9 @@ def _expected_attestation(
         limit=1_000_000,
         label="artifact attestation release contract",
     )
+    transition = release.provenance_mode == "authority-transition-bootstrap"
     return {
-        "schemaVersion": 1,
+        "schemaVersion": 2 if transition else 1,
         "kind": ATTESTATION_KIND,
         "checkpoint": checkpoint,
         "release": {
@@ -332,6 +336,20 @@ def _expected_attestation(
             authorization_path,
             checkpoint=checkpoint,
         ),
+        **(
+            {
+                "authorityTransition": {
+                    "sourceAuthority": {
+                        "version": release.transition_source_version,
+                        "digest": release.transition_source_digest,
+                    },
+                    "skippedRelease": release.transition_skipped_version,
+                    "bootstrapChangeId": release.transition_change_id,
+                }
+            }
+            if transition
+            else {}
+        ),
         "artifacts": _artifact_entries(artifact_root, release),
     }