engineering-process 0.4.0__tar.gz → 0.5.1__tar.gz

engineering_process-0.5.1/MANIFEST.in

@@ -0,0 +1,2 @@
+# Package inputs are explicitly declared in pyproject.toml. Archive verification
+# rejects managed, generated, and bytecode paths from both wheel and sdist outputs.

{engineering_process-0.4.0/engineering_process.egg-info → engineering_process-0.5.1}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: engineering-process
-Version: 0.4.0
+Version: 0.5.1
 Summary: Agent-neutral end-to-end engineering lifecycle and deterministic process CLI
 License-Expression: MIT
 Project-URL: Homepage, https://github.com/phuongnse/engineering-process
@@ -78,6 +78,13 @@ checkpoint and workspace fingerprint.
 
 ## Execution architecture
 
+Validated failures participate in a federated improvement loop. Consumers export
+bounded, redacted signals to the owning producer without granting authority;
+producer triage, lifecycle completion, immutable release, consumer adoption, and
+consumer reproduction remain separate gates. `processctl improvement status` exposes
+the portable chain and next owner. See
+[PROCESS_IMPROVEMENT.md](PROCESS_IMPROVEMENT.md).
+
 Consumers use one foreground-task contract on every supported platform. The contract
 owns argument-array commands, non-interactive standard input, bounded output, timeout,
 exit status, and descendant cleanup. Platform selection occurs once inside the
@@ -85,9 +92,10 @@ distribution: the POSIX backend owns a new process session/group and the Windows
 backend owns a kill-on-close Job Object. Consumer manifests, evidence, and exit codes
 do not branch by operating system. If an outer Windows Job applies incompatible
 nesting or UI limits, target creation fails closed instead of running uncontained.
-After a command root exits, both backends allow at most 250 milliseconds for child
-accounting to drain naturally. A process still present after that bound is terminated
-and makes the command fail; commands with no remaining child return immediately.
+After a command root exits, the POSIX backend allows at most 250 milliseconds and the
+Windows Job Object backend allows at most 5 seconds for child accounting to drain
+naturally. A process still present after its platform bound is terminated and makes
+the command fail; commands with no remaining child return immediately.
 
 This task boundary intentionally separates finite commands from services and
 interactive protocols. `processctl exec`, requirement probes, setup command actions,
@@ -97,6 +105,14 @@ commands outside this executor until a separate service or interactive lifecycle
 specified. They must not be placed in verification profiles or wrapped by
 `processctl exec`.
 
+A finite command succeeds only when its process boundary passes and its complete
+admitted stdout and stderr are free of classified warning and error diagnostics. The
+shared classifier is bounded and non-configurable. Exit-zero diagnostics therefore
+fail `doctor`, `setup`, `exec`, verification, and internal distribution commands at
+the shared owner. Reports retain redacted diagnostic metadata and line digests, not
+raw matched text. Fix the warning or error at its owner; do not silence it, replace
+the canonical command, or set a tool-specific suppression variable to obtain a pass.
+
 ## Consumer bootstrap
 
 Add only project-owned configuration:
@@ -159,10 +175,12 @@ 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, a published version is adopted through one Renovate draft.
+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. If the
-consumer chooses or requires new project configuration, it adds
+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
 `.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
@@ -368,7 +386,8 @@ component closure, check routing, and evidence remain distribution-owned.
 
 Select capability bundles from `bundles.json`: every consumer starts with `core`,
 then adds only capabilities it actually owns. For example, a web product commonly
-adds `delivery`, `product`, `api`, `frontend`, `docs`, and `publication`. Add
+adds `delivery`, `product`, `api`, `frontend`, and `docs`. Publication from a
+completed checkpoint is part of the mandatory core chain. Add
 `cross-repo` only when independently versioned repositories participate in one
 public-contract change. Re-run `project init ... --replace` with the intended bundle
 set when deliberately changing the pin; version remains unchanged during an
@@ -387,6 +406,12 @@ through its public N-1 self-hosting boundary.
 Agents enter non-trivial delivery through the synchronized `run-change` skill; phase
 skills are internal owners, not a workflow each project must reconnect.
 
+`process-graph.json` is the machine-readable owner for that chain. It binds every
+phase to one owner skill, permitted `processctl` commands, success/failure outcomes,
+next phase/skill, and the standing-policy merge boundary. Distribution validation rejects
+missing skills, non-core chain owners, nonexistent commands, unknown phases, and
+broken handoffs; prose skills explain the graph but do not replace it.
+
 ## Canonical lifecycle
 
 Create a change contract from `examples/change.json` and a plan from
@@ -448,7 +473,26 @@ through a fail-closed migration that replays immutable review artifacts to recon
 pending findings before any transition is allowed.
 
 Completion does not imply commit creation, push, merge, release, or deployment.
-Those remain separately authorized project workflows.
+Those remain separately gated project workflows. A valid `.process/automation.json`
+provides standing authorization, so the host continues each operation automatically
+after its owning gate instead of asking for repeated confirmation. An owner directive
+may authorize installing that policy but never substitutes for a missing policy.
+
+When new evidence exposes multiple materially valid directions or would change
+accepted scope, owner, trust boundary, authority, compatibility, rollout, or
+lifecycle order, the coordinator stops dependent mutation and asks the project owner.
+It presents evidence, the invariant, real options, trade-offs, and a recommendation;
+the accepted decision is recorded before work resumes. Bounded implementation details
+already decided by the contract continue autonomously.
+
+The canonical publication order is stricter than a PR-first workflow: implementation
+and every required 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
+completion; only then may automation push and create the PR. Static policy/secret/pin
+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.
 
 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:
@@ -480,6 +524,10 @@ processctl publication validate-range --project-root . \
   --branch feat/short-description --range origin/main..HEAD
 processctl publication validate-pr --title "feat(scope): describe the change" \
   --branch feat/short-description --state draft --body-file pr.md
+processctl publication validate-source --project-root . \
+  --change-id issue-123 --commit <completed-checkpoint> \
+  --title "feat(scope): describe the change" \
+  --branch feat/short-description --body-file pr.md
 processctl contract validate --kind release release.json
 processctl publication validate-release --project-root . \
   --tag v0.2.0 --release-name v0.2.0 \
@@ -500,6 +548,90 @@ remains responsible for the semantic truth of project-specific evidence.
 Raw HTML is outside the supported grammar for both managed `AGENTS.md` contracts and
 pull-request descriptions; use visible CommonMark instead.
 
+`validate-pr` remains a metadata-compatibility command. `validate-source` is the
+canonical publication gate and requires current completion evidence for the exact
+commit, regardless of provider draft/ready presentation.
+
+### Standing gated automation
+
+Projects opt into unattended routine operation with `.process/automation.json`, using
+the packaged `automation-policy` schema. The exact policy authorizes commit, push,
+review-object publication, merge, release, publication, deployment, adoption, and
+ephemeral cleanup only after their existing gates. Merge always requires completed
+lifecycle evidence, fresh independent review, exact head, current protected base,
+required checks, branch protection, and the configured merge method. Missing or
+invalid policy grants no authority.
+
+The confirmation mode is `exceptions-only`. Automation involves the owner only when a
+required capability or authority is unavailable, bounded idempotent recovery is
+exhausted, or a material product/security decision is missing. Pending checks,
+ordinary retries, routine merges, and already authorized external actions continue
+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.
+
+The immutable provider verifier emits one bounded
+`engineering-process-controlled-automation-proposal` report for the exact repository,
+base/head, changed paths, title/body digest, owner, controls, and verifier revision.
+The adapter resolves `--base-commit` independently from the provider's current target
+event; it must not copy that value from the report being checked. Before creating or
+updating a proposal, validate the report against the clean source:
+
+~~~text
+processctl contract validate --kind automation-proposal-policy \
+  .process/automation-proposals.json
+processctl contract validate --kind automation-proposal proposal-policy.json
+processctl publication validate-proposal --project-root . \
+  --policy-evidence proposal-policy.json \
+  --repository <owner/repository> --commit <head-sha> \
+  --title "chore(deps): update dependencies" \
+  --branch automation/renovate/dependencies --target-branch main \
+  --base-commit <protected-base-sha> \
+  --state draft --body-file pr.md \
+  --verifier-repository <owner/verifier> --verifier-commit <verifier-sha>
+~~~
+
+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.
+
+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,
+and have the same immutable verifier produce fresh policy evidence bound to the final
+ready body and unchanged base/head. Then run the combined gate:
+
+~~~text
+processctl publication validate-proposal-completion --project-root . \
+  --policy-evidence proposal-policy.json \
+  --evidence completion.json --evidence-kind receipt \
+  --repository <owner/repository> --commit <head-sha> \
+  --title "chore(deps): update dependencies" \
+  --branch automation/renovate/dependencies --target-branch main \
+  --base-commit <protected-base-sha> \
+  --body-file ready-pr.md \
+  --verifier-repository <owner/verifier> --verifier-commit <verifier-sha>
+~~~
+
+Only a successful combined gate permits the provider adapter to create
+`lifecycle-completion` for that exact SHA. A force update has no inherited check;
+branch protection must require the proposal to be current with the exact validated
+base; duplicate mismatch fails closed. Historical schema-1 policy remains human-only.
+Schema 2 keeps provider automerge disabled before completion and permits merge only
+after the protected base's standing automation policy and exact completion gate pass.
+Provider tokens, check APIs, branch protection, retries, and repository selection
+remain consumer-owned adapter behavior.
+
 ## Trust boundary
 
 The CLI proves structural separation: reviewer actor id and context id must both be
@@ -511,11 +643,58 @@ conversation, pass stable identities to `change review start`, and preserve its
 evidence. A stable reviewer actor or role may be reused with a fresh context; merely
 renaming retained context does not satisfy the process.
 
+Self-hosted verifier, signing, release-controller, and process-authority changes use
+the portable authority-rotation rule: the old trust root governs introduction, the
+new root is published under an immutable identity before consumers pin it, cutover is
+proved without a control gap, and retirement happens only after the new boundary is
+active. Provider-specific mechanics may require multiple independently completed
+changes; normal product changes do not inherit that staging automatically.
+
 `change review submit` may be invoked by a coordinator transporting the assigned
 reviewer's exact report. The CLI validates that artifact against the assignment and
 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.
+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
+gzip/base64 evidence to `release-approval.yml`; semantic reports and reviewer selection
+never become workflow inputs. The publication workflow validates the receipt against
+the exact clean source with `publication validate-evidence-source`, and only then
+pushes the branch, creates or reconciles the ready PR, validates the standing policy,
+and enables exact-head protected auto-merge. No workflow bypasses branch protection.
+
+The host callback is deterministic after semantic completion:
+
+~~~text
+processctl evidence export --change-id <change-id> --output completion.json
+processctl evidence encode-completion --evidence completion.json \
+  --evidence-kind receipt --output completion.txt
+gh workflow run release-approval.yml --ref main \
+  -f verified_run_id=<verified-run-id> \
+  -f comparison_base=<base-sha> \
+  -f release_head_sha=<completed-checkpoint> \
+  -f completion_evidence_gzip_base64="$(<completion.txt)"
+~~~
+
+The callback `comparison_base` is the candidate source base: the immediate protected
+`main` parent used for source restoration, current-base checks, and the publication
+range. The receipt's lifecycle comparison base is independently owned by
+`.release/change.json` and normally identifies the previous immutable release tag;
+the publication boundary validates both identities against their respective owners.
+An older callback whose candidate source base is no longer current fails before any
+candidate-owned publication adapter is invoked.
+
+A bootstrap-authority release uses `evidence export-bootstrap` and
+`--evidence-kind bootstrap-authorization`. The adapter rejects oversized or malformed
+transport, a different process identity, base, project, checkpoint, workspace
+fingerprint, source tree, or publication range.
+
 ## Distribution contracts
 
 - `project.json` declares baseline profiles and exact argument-array checks.
@@ -544,12 +723,15 @@ authenticates who produced it.
   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.
-- Remote matrix jobs publish one bounded supplemental-verification schema-1 bundle
+- Remote matrix jobs publish one bounded supplemental-verification schema-2 bundle
   per platform/runtime. Its manifest binds the exact source and workflow checkpoints,
   automation actor/context, run URL, platform/runtime identity, selected impact,
-  configured timeouts, output byte counts/digests, truncation state, and the hashes of
-  its schema-2 profile reports. GitHub's artifact id and digest complete the immutable
-  remote reference; this supplements rather than replaces N-1 lifecycle evidence.
+  configured timeouts, output byte counts/digests, redacted diagnostic summaries,
+  truncation state, and the hashes of its schema-3 profile reports. Historical
+  supplemental schema-1 bundles and verification schema-1/schema-2 reports remain
+  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
@@ -583,7 +765,7 @@ authenticates who produced it.
 ~~~text
 python -m venv .venv
 .venv/bin/python -m pip install -e '.[dev]'
-.venv/bin/python -m unittest discover -s tests -p 'test_*.py'
+.venv/bin/python verification/run_test_suite.py
 .venv/bin/python processctl.py skills validate --root process_assets/skills
 .venv/bin/python processctl.py digest
 ~~~

engineering_process-0.5.1/PROCESS_IMPROVEMENT.md

@@ -0,0 +1,132 @@
+# Federated process improvement
+
+This document owns the public feedback protocol that turns validated failures into
+local correction or shared process evolution without transferring repository
+authority.
+
+## Ownership
+
+A consumer owns its project behavior, exact evidence, local lifecycle, publication,
+and adoption decisions. A process producer owns portable lifecycle semantics,
+schemas, CLI enforcement, invariant classification, releases, and the public
+improvement catalog. A transport moves immutable artifacts and may attest delivery;
+it owns neither side's implementation, merge, release, nor adoption.
+
+Consumer evidence is untrusted producer input. A signal can trigger triage but never
+authorizes mutation. A producer disposition can classify and link work but never
+authorizes implementation or delivery. A completed producer change does not prove an
+immutable release or consumer recovery.
+
+## Artifact chain
+
+The portable chain contains four independent schema-1 JSON artifacts:
+
+1. `engineering-process-improvement-signal` binds the consumer project, repository,
+   checkpoint, process lock, trigger, owner claim, proposed invariant, bounded
+   evidence hashes, and target producer. It contains no raw output, environment,
+   secrets, credentials, or authority grant.
+2. `engineering-process-improvement-disposition` is producer-owned triage. It binds
+   the canonical signal digest, assigns the canonical invariant and reusable class,
+   records new, duplicate, or recurring status, and links accepted work to a producer
+   lifecycle. Rejection is explicit and evidence-backed.
+3. `engineering-process-improvement-resolution` binds an accepted disposition to a
+   completed producer lifecycle receipt and one immutable public release. It grants
+   no consumer adoption authority.
+4. `engineering-process-improvement-reproduction` binds the producer version, tag,
+   release name, commit, and artifact-set digest to a clean consumer checkpoint, its
+   selected-skill process-lock digest, and passing project-owned profiles. Only this
+   artifact closes a shared consumer case.
+
+Every later artifact carries canonical digests for every prior artifact. Validation
+is bounded by item count, document bytes, aggregate bytes, identifier size, and URI
+size. Core reads and writes local files only. GitHub issues, dispatches, MCP calls,
+queues, or other delivery mechanisms are optional adapters and must preserve exact
+artifact bytes.
+
+## Lifecycle gates
+
+A rejected governed verification profile or unresolved independent-review finding
+creates a pending improvement case. Corrective work cannot silently advance through
+another verification, completion, or source publication while classification is
+missing.
+
+Classification records:
+
+- owner boundary: `project-local`, `shared-process`, `operations-or-external`, or
+  `missing-product-or-authorization-input`;
+- reusable class: local behavior, process rule, deterministic enforcement,
+  portability gap, or obsolete guidance;
+- canonical or proposed invariant id;
+- explicit local, shared, external, input, or producer disposition;
+- a rationale digest and, for shared escalation, the producer target.
+
+A reviewed local fix may close at lifecycle completion. An accepted inbound producer
+case may reach producer completion but stays release-owned until an immutable
+resolution exists. A shared consumer case stays incomplete until disposition,
+resolution, and reproduction all validate.
+
+`producer-improvement` classifies a shared-process defect discovered in the producer's
+own governed work. It remains local producer lifecycle work and requires the reviewed
+catalog to activate the same invariant and change before completion; it does not
+fabricate a consumer signal. Inbound consumer evidence enters only through
+`improvement ingest` and retains the complete signal/catalog/disposition receipt
+boundary.
+
+`processctl change status` reports every local, producer, and consumer case, including
+proposed and canonical invariant ids, recurrence, catalog status and digest,
+producer/change, immutable release, consumer checkpoint/process identity, artifact
+source and canonical digests, blockers, and next owner. The public projection omits
+private lifecycle artifact paths.
+`processctl improvement status` reports a transported artifact chain without reading
+either repository's private lifecycle files.
+
+## Recurrence
+
+`improvement-catalog.json` is producer-owned and versioned with the distribution. It
+contains canonical invariant ids, reusable classes, public surfaces, status, and
+public resolving change/release identity. It never contains consumer repository
+identity or incident evidence.
+
+A new signal assigned to a resolved catalog invariant is a recurrence. It cannot be
+closed as another non-shared narrow incident unless the producer disposition carries
+an explicit owner-approved exception and evidence digest. An active invariant yields
+a duplicate disposition linked to existing work. A new semantic class is added only
+through a reviewed producer lifecycle. Before that producer lifecycle can complete,
+the reviewed distribution catalog must contain the canonical invariant as `active`,
+with the same reusable class and `activeChangeId` as the selected lifecycle. Release
+PR materialization resolves only entries whose active change is in the exact release
+change set.
+
+## Release and adoption
+
+Producer completion, producer release, consumer adoption, and consumer reproduction
+are separate boundaries:
+
+1. Public N-1 governs and reviews the producer capability.
+2. The owner separately authorizes one immutable producer release.
+3. A consumer independently adopts that release under its currently pinned public
+   authority. It never commits a dependency on the producer working tree.
+4. The consumer reruns the exact affected boundary and exports reproduction evidence.
+5. Aggregate improvement closes only when producer and consumer proof are both valid.
+
+Before release, a read-only candidate artifact may provide forward compatibility
+evidence at a real consumer. It is supplemental proof, not a production dependency,
+adoption, publication, or merge authorization.
+
+## Commands
+
+~~~text
+processctl improvement classify ...
+processctl improvement observe ...
+processctl improvement export-signal ...
+processctl improvement disposition ...
+processctl improvement ingest ...
+processctl improvement resolution ...
+processctl improvement reproduction ...
+processctl improvement attach ...
+processctl improvement validate-chain ...
+processctl improvement status ...
+~~~
+
+All mutation commands operate only on the selected local project and explicit output
+files. No improvement command performs network work or mutates another repository.

{engineering_process-0.4.0 → engineering_process-0.5.1}/PRODUCTION_STANDARD.md

@@ -46,18 +46,30 @@ Environment probe regular expressions evaluate a bounded view whose CRLF and CR
 boundaries are canonicalized to LF. Captured output, byte counts, truncation state,
 and digests retain the original bytes so portability does not weaken evidence.
 
+Process-owned finite commands pass only when execution is otherwise successful and
+the complete admitted stdout and stderr streams are free of classified warning and
+error diagnostics. The distribution owns one bounded, non-configurable classifier;
+an exit code of zero cannot override a diagnostic failure. Projects correct the
+diagnostic at its owning boundary rather than suppressing output, changing the
+canonical command, or installing a consumer wrapper. Durable reports record only the
+policy, severity, stream, line number, bounded count, truncation state, and line
+SHA-256. They never copy the diagnostic line into lifecycle evidence.
+
 Missing, stale, truncated beyond a declared policy, blocked, or unverifiable evidence
 never becomes a pass. Independent review records each accepted dimension as
 `verified`, `failed`, or `not-applicable-confirmed`; lifecycle submission compares
 that evidence one-for-one with the change contract before approval.
 
 Remote matrix claims require one bounded supplemental bundle per platform/runtime.
-The schema-1 manifest binds the exact source and workflow checkpoints, automation
-actor/context, run identity and URL, platform/runtime identity, selected impact,
-configured timeouts, output byte counts/digests, truncation state, and the hashes of
-its schema-2 profile reports. The remote artifact id and service-computed digest are
-preserved with review evidence. These reports supplement the public N-1 lifecycle
-authority; code under verification never promotes itself to lifecycle authority.
+The current schema-2 manifest binds the exact source and workflow checkpoints,
+automation actor/context, run identity and URL, platform/runtime identity, selected
+impact, configured timeouts, output byte counts/digests, diagnostic summaries,
+truncation state, and the hashes of its schema-3 profile reports. Historical
+supplemental schema-1 manifests and verification schema-1/schema-2 reports retain
+their released reader semantics. The remote artifact id and service-computed digest
+are preserved with review evidence. These reports supplement the public N-1
+lifecycle authority; code under verification never promotes itself to lifecycle
+authority.
 
 ## Failure to invariant
 
@@ -68,6 +80,14 @@ authorization input. Dependent candidates stay blocked. Shared defects are corre
 in the producer rather than wrapped or duplicated by consumers; project behavior
 remains project-owned unless a portable class is proven.
 
+Every governed verification failure and unresolved review finding has a structured
+improvement disposition before corrective progress. A shared consumer case exports a
+bounded untrusted signal and remains incomplete until a producer disposition,
+completed-lifecycle and immutable-release resolution, and exact consumer reproduction
+all validate. A failure assigned to an already resolved catalog invariant is a
+recurrence and requires producer-owned process evolution or an explicit owner-approved
+exception. See `PROCESS_IMPROVEMENT.md`.
+
 Every correction proves valid behavior and the corresponding fail-closed class at the
 lowest reliable owner boundary. Shared corrections additionally require producer
 profiles and reproduction at affected consumer boundaries before release. A transient
@@ -122,6 +142,21 @@ policy. This keeps distribution input bytes platform-independent. The producer
 root policy is not a consumer-managed asset and is never written by bootstrap or
 sync.
 
+## Standing gated automation
+
+A project-owned standing policy may authorize unattended commit, push,
+review-object, exact-head merge, release, publication, deployment, adoption, and
+ephemeral cleanup only after the existing owning gates pass. It never weakens
+lifecycle completion, fresh independent review, exact head/base, required checks,
+branch protection, consumer ownership, release identity, or destructive-target
+validation. Provider automerge remains disabled for untrusted pre-completion
+proposals.
+
+Owner involvement is exceptions-only: a required capability or authority is
+unavailable, bounded idempotent recovery is exhausted, or a material product/security
+decision is missing. Pending checks, normal bounded retries, and routine authorized
+merge or publication operations continue automatically with durable diagnostics.
+
 ## Release identity
 
 The release contract is the source of truth for package name, distribution name,