engineering-process 1.1.2__tar.gz → 1.2.0__tar.gz

{engineering_process-1.1.2 → engineering_process-1.2.0}/MANIFEST.in

@@ -1,4 +1,4 @@
 include process-graph.json
-recursive-include process_assets/skills SKILL.md
+recursive-include process_assets/skills SKILL.md *.json
 recursive-include schemas *.json
 recursive-include templates *.md *.py

{engineering_process-1.1.2/engineering_process.egg-info → engineering_process-1.2.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: engineering-process
-Version: 1.1.2
+Version: 1.2.0
 Summary: A small agent-neutral engineering lifecycle with managed adoption
 License-Expression: MIT
 Project-URL: Homepage, https://github.com/phuongnse/engineering-process
@@ -37,9 +37,9 @@ release decisions.
 
 The distribution has four live parts:
 
-1. Eight skills under process_assets/skills, all reachable from run-change.
+1. Managed skills under process_assets/skills, all reachable from run-change.
 2. One processctl state machine under engineering_process/lifecycle.py.
-3. Eleven JSON Schemas that are loaded directly by the runtime.
+3. JSON Schemas that are loaded directly by the runtime.
 4. One adoption transaction that synchronizes managed skills and configuration from
    an exact hash-locked package.
 
@@ -53,6 +53,12 @@ may have implemented the current cycle. There is no attestation hierarchy,
 recommendation chain, authority-transition protocol, remote-evidence federation, or
 second handwritten validator.
 
+Runtime architecture is enforced by semantic fitness functions, not module or source-
+line quotas. Every module has an explicit dependency layer, imports point toward lower
+layers, the internal graph remains acyclic, and lifecycle.py alone owns state
+transitions behind the CLI adapter. Size metrics may guide refactoring but do not
+decide correctness or release eligibility.
+
 ## Consumer configuration
 
 Python 3.11 or newer and Git are required. A consumer owns .process/project.json:
@@ -138,6 +144,37 @@ runtime/license delivery, Linux advisory resolution, real-host workspace securit
 updater, incident recovery, and independent security review remain planned.
 Consumers without readiness remain compatible during that evidence-backed rollout.
 
+### Production engineering invariants
+
+Every new plan and independent review applies one small, versioned invariant floor:
+
+- authoritative structure for open-world decisions;
+- one authoritative source for shared policy;
+- bounded, least-authority side effects;
+- explicit compatibility and migration boundaries;
+- assurance bound to current objective evidence and independent judgment.
+
+The canonical triggers, required structures, prohibited failures, and expected
+evidence live once in the managed `production-engineering/invariants.json` asset.
+They are cross-domain invariants, not a catalog of preferred design patterns. A
+closed, owner-versioned protocol may use literal state or enum tables; automation
+must not guess open-world meaning from keywords, identifiers, filenames, diagnostic
+text, or growing exception lists.
+
+Plan schema version 5 requires a reasoned applicability decision for every invariant
+and real work-item references for each applicable entry. A change started by this
+authority records that writer requirement before planning. The public reader retains
+schema version 4 so a run started by an earlier 1.x authority can still validate and
+register its old plan; that registration is assigned review schema version 6. Review
+schema version 7 requires an independent result and evidence for each entry. A
+violation links to a blocking finding, so it cannot coexist with approval. Structural
+completeness is machine-enforced; the reviewer remains responsible for contextual
+truth.
+
+This assessment is not a production certificate. Production still requires the
+consumer's immutable readiness pack, every required capability in `enforced` state,
+fresh consumer-owned verification on the exact candidate, and independent review.
+
 For each ordinary change, `run-change` first surfaces this readiness view. The accepted
 request and consumer rules determine which capabilities are affected. Every change
 retains the project's baseline `requiredProfiles`; start and plan add any conditional
@@ -200,7 +237,7 @@ assigned checkpoint:
     }
 
     {
-      "schemaVersion": 4,
+      "schemaVersion": 5,
       "changeId": "change-123",
       "contractDigest": "sha256:0000000000000000000000000000000000000000000000000000000000000000",
       "approach": "Implement through the existing owner.",
@@ -211,11 +248,43 @@ assigned checkpoint:
           "affectedPaths": ["src/", "tests/"]
         }
       ],
-      "risks": []
+      "risks": [],
+      "productionEngineering": [
+        {
+          "id": "authoritative-structure",
+          "applicability": "not-applicable",
+          "rationale": "The change does not classify an extensible vocabulary.",
+          "evidenceWorkItems": []
+        },
+        {
+          "id": "single-policy-authority",
+          "applicability": "not-applicable",
+          "rationale": "The change introduces no shared policy authority.",
+          "evidenceWorkItems": []
+        },
+        {
+          "id": "bounded-side-effects",
+          "applicability": "not-applicable",
+          "rationale": "The change introduces no resource-bearing side effect.",
+          "evidenceWorkItems": []
+        },
+        {
+          "id": "contractual-evolution",
+          "applicability": "not-applicable",
+          "rationale": "The change does not alter a persisted or public contract.",
+          "evidenceWorkItems": []
+        },
+        {
+          "id": "evidence-bound-assurance",
+          "applicability": "applicable",
+          "rationale": "Completion must be proven on the exact candidate.",
+          "evidenceWorkItems": ["implementation"]
+        }
+      ]
     }
 
     {
-      "schemaVersion": 5,
+      "schemaVersion": 7,
       "changeId": "change-123",
       "reviewer": {
         "actorId": "review-agent",
@@ -230,9 +299,59 @@ assigned checkpoint:
       },
       "verdict": "approved",
       "summary": "Accepted outcomes and evidence are complete.",
-      "findings": []
+      "findings": [],
+      "productionEngineering": [
+        {
+          "id": "authoritative-structure",
+          "status": "not-applicable",
+          "rationale": "No open-world classification is present.",
+          "evidence": []
+        },
+        {
+          "id": "single-policy-authority",
+          "status": "not-applicable",
+          "rationale": "No shared policy authority is present.",
+          "evidence": []
+        },
+        {
+          "id": "bounded-side-effects",
+          "status": "not-applicable",
+          "rationale": "No resource-bearing side effect is present.",
+          "evidence": []
+        },
+        {
+          "id": "contractual-evolution",
+          "status": "not-applicable",
+          "rationale": "No persisted or public contract changed.",
+          "evidence": []
+        },
+        {
+          "id": "evidence-bound-assurance",
+          "status": "satisfied",
+          "rationale": "Required profiles passed on the assigned snapshot.",
+          "evidence": ["development and review profile reports"]
+        }
+      ],
+      "processImprovement": {
+        "status": "none",
+        "rationale": "No reusable shared-process problem was observed."
+      }
     }
 
+`change review start` returns the exact `reportSchemaVersion` for its assignment and
+bounded `processSignals` derived from existing lifecycle events. Signals are prompts
+for independent judgment, not evidence that hidden external actions occurred.
+Version 6 distinguishes priority from severity: priority records impact if unresolved,
+while severity alone controls the current lifecycle gate. Every non-blocking finding
+in versions 6 and 7 records one disposition: `resolved` with a rationale, or
+`accepted-risk` / `tracked-follow-up` with a rationale, owner, and stable HTTPS
+`recordUrl`. Version 7 adds the production-engineering resolution and requires a
+`processImprovement` classification of `none`, `consumer-specific`, or
+`shared-process`. A shared-process report requires an existing, owner-authorized issue
+URL; without it, the review remains pending. Earlier plan and review documents remain
+readable, and their runs remain registrable or finishable with the version selected by
+the authority that started the relevant phase.
+
 ## Running a change
 
 Create and validate a change contract, then register it:
@@ -287,6 +406,27 @@ approved can finish only while the repository still matches the reviewed snapsho
       --actor coordinator \
       --context finish-123
 
+### Public pull-request evidence
+
+The managed pull-request template keeps public assurance separate from local
+lifecycle identity. Its five sections and labeled fields are ordered and stable:
+outcome and scope; source, risk, compatibility, and stack; profiles, snapshot, and
+completion receipt; verdict, cycles, blocking status, and non-blocking dispositions;
+and a distinct completion gate for the overall assertions.
+The public description never needs an actor ID, context ID, reviewer
+handle, or local `.process/runs` path. Those values remain in lifecycle state, where
+they enforce self-review rejection but do not pretend to be provider-authenticated
+review identities.
+
+`processctl publication validate-pr` checks that public contract deterministically.
+It rejects missing, repeated, misplaced, hidden, unordered, or unsupported visible
+structure. Completion checkboxes belong only to the Completion gate section. Ready
+pull requests must have every checkbox checked; drafts may retain unchecked work.
+The managed template never solicits execution identity,
+and authors plus independent review keep it out of free-form values. The validator is
+a positive grammar for public fields; it deliberately does not guess identities from
+an open-ended vocabulary of names or labels.
+
 At any point:
 
     processctl change status --change-id change-123 --json

{engineering_process-1.1.2 → engineering_process-1.2.0}/README.md

@@ -13,9 +13,9 @@ release decisions.
 
 The distribution has four live parts:
 
-1. Eight skills under process_assets/skills, all reachable from run-change.
+1. Managed skills under process_assets/skills, all reachable from run-change.
 2. One processctl state machine under engineering_process/lifecycle.py.
-3. Eleven JSON Schemas that are loaded directly by the runtime.
+3. JSON Schemas that are loaded directly by the runtime.
 4. One adoption transaction that synchronizes managed skills and configuration from
    an exact hash-locked package.
 
@@ -29,6 +29,12 @@ may have implemented the current cycle. There is no attestation hierarchy,
 recommendation chain, authority-transition protocol, remote-evidence federation, or
 second handwritten validator.
 
+Runtime architecture is enforced by semantic fitness functions, not module or source-
+line quotas. Every module has an explicit dependency layer, imports point toward lower
+layers, the internal graph remains acyclic, and lifecycle.py alone owns state
+transitions behind the CLI adapter. Size metrics may guide refactoring but do not
+decide correctness or release eligibility.
+
 ## Consumer configuration
 
 Python 3.11 or newer and Git are required. A consumer owns .process/project.json:
@@ -114,6 +120,37 @@ runtime/license delivery, Linux advisory resolution, real-host workspace securit
 updater, incident recovery, and independent security review remain planned.
 Consumers without readiness remain compatible during that evidence-backed rollout.
 
+### Production engineering invariants
+
+Every new plan and independent review applies one small, versioned invariant floor:
+
+- authoritative structure for open-world decisions;
+- one authoritative source for shared policy;
+- bounded, least-authority side effects;
+- explicit compatibility and migration boundaries;
+- assurance bound to current objective evidence and independent judgment.
+
+The canonical triggers, required structures, prohibited failures, and expected
+evidence live once in the managed `production-engineering/invariants.json` asset.
+They are cross-domain invariants, not a catalog of preferred design patterns. A
+closed, owner-versioned protocol may use literal state or enum tables; automation
+must not guess open-world meaning from keywords, identifiers, filenames, diagnostic
+text, or growing exception lists.
+
+Plan schema version 5 requires a reasoned applicability decision for every invariant
+and real work-item references for each applicable entry. A change started by this
+authority records that writer requirement before planning. The public reader retains
+schema version 4 so a run started by an earlier 1.x authority can still validate and
+register its old plan; that registration is assigned review schema version 6. Review
+schema version 7 requires an independent result and evidence for each entry. A
+violation links to a blocking finding, so it cannot coexist with approval. Structural
+completeness is machine-enforced; the reviewer remains responsible for contextual
+truth.
+
+This assessment is not a production certificate. Production still requires the
+consumer's immutable readiness pack, every required capability in `enforced` state,
+fresh consumer-owned verification on the exact candidate, and independent review.
+
 For each ordinary change, `run-change` first surfaces this readiness view. The accepted
 request and consumer rules determine which capabilities are affected. Every change
 retains the project's baseline `requiredProfiles`; start and plan add any conditional
@@ -176,7 +213,7 @@ assigned checkpoint:
     }
 
     {
-      "schemaVersion": 4,
+      "schemaVersion": 5,
       "changeId": "change-123",
       "contractDigest": "sha256:0000000000000000000000000000000000000000000000000000000000000000",
       "approach": "Implement through the existing owner.",
@@ -187,11 +224,43 @@ assigned checkpoint:
           "affectedPaths": ["src/", "tests/"]
         }
       ],
-      "risks": []
+      "risks": [],
+      "productionEngineering": [
+        {
+          "id": "authoritative-structure",
+          "applicability": "not-applicable",
+          "rationale": "The change does not classify an extensible vocabulary.",
+          "evidenceWorkItems": []
+        },
+        {
+          "id": "single-policy-authority",
+          "applicability": "not-applicable",
+          "rationale": "The change introduces no shared policy authority.",
+          "evidenceWorkItems": []
+        },
+        {
+          "id": "bounded-side-effects",
+          "applicability": "not-applicable",
+          "rationale": "The change introduces no resource-bearing side effect.",
+          "evidenceWorkItems": []
+        },
+        {
+          "id": "contractual-evolution",
+          "applicability": "not-applicable",
+          "rationale": "The change does not alter a persisted or public contract.",
+          "evidenceWorkItems": []
+        },
+        {
+          "id": "evidence-bound-assurance",
+          "applicability": "applicable",
+          "rationale": "Completion must be proven on the exact candidate.",
+          "evidenceWorkItems": ["implementation"]
+        }
+      ]
     }
 
     {
-      "schemaVersion": 5,
+      "schemaVersion": 7,
       "changeId": "change-123",
       "reviewer": {
         "actorId": "review-agent",
@@ -206,9 +275,59 @@ assigned checkpoint:
       },
       "verdict": "approved",
       "summary": "Accepted outcomes and evidence are complete.",
-      "findings": []
+      "findings": [],
+      "productionEngineering": [
+        {
+          "id": "authoritative-structure",
+          "status": "not-applicable",
+          "rationale": "No open-world classification is present.",
+          "evidence": []
+        },
+        {
+          "id": "single-policy-authority",
+          "status": "not-applicable",
+          "rationale": "No shared policy authority is present.",
+          "evidence": []
+        },
+        {
+          "id": "bounded-side-effects",
+          "status": "not-applicable",
+          "rationale": "No resource-bearing side effect is present.",
+          "evidence": []
+        },
+        {
+          "id": "contractual-evolution",
+          "status": "not-applicable",
+          "rationale": "No persisted or public contract changed.",
+          "evidence": []
+        },
+        {
+          "id": "evidence-bound-assurance",
+          "status": "satisfied",
+          "rationale": "Required profiles passed on the assigned snapshot.",
+          "evidence": ["development and review profile reports"]
+        }
+      ],
+      "processImprovement": {
+        "status": "none",
+        "rationale": "No reusable shared-process problem was observed."
+      }
     }
 
+`change review start` returns the exact `reportSchemaVersion` for its assignment and
+bounded `processSignals` derived from existing lifecycle events. Signals are prompts
+for independent judgment, not evidence that hidden external actions occurred.
+Version 6 distinguishes priority from severity: priority records impact if unresolved,
+while severity alone controls the current lifecycle gate. Every non-blocking finding
+in versions 6 and 7 records one disposition: `resolved` with a rationale, or
+`accepted-risk` / `tracked-follow-up` with a rationale, owner, and stable HTTPS
+`recordUrl`. Version 7 adds the production-engineering resolution and requires a
+`processImprovement` classification of `none`, `consumer-specific`, or
+`shared-process`. A shared-process report requires an existing, owner-authorized issue
+URL; without it, the review remains pending. Earlier plan and review documents remain
+readable, and their runs remain registrable or finishable with the version selected by
+the authority that started the relevant phase.
+
 ## Running a change
 
 Create and validate a change contract, then register it:
@@ -263,6 +382,27 @@ approved can finish only while the repository still matches the reviewed snapsho
       --actor coordinator \
       --context finish-123
 
+### Public pull-request evidence
+
+The managed pull-request template keeps public assurance separate from local
+lifecycle identity. Its five sections and labeled fields are ordered and stable:
+outcome and scope; source, risk, compatibility, and stack; profiles, snapshot, and
+completion receipt; verdict, cycles, blocking status, and non-blocking dispositions;
+and a distinct completion gate for the overall assertions.
+The public description never needs an actor ID, context ID, reviewer
+handle, or local `.process/runs` path. Those values remain in lifecycle state, where
+they enforce self-review rejection but do not pretend to be provider-authenticated
+review identities.
+
+`processctl publication validate-pr` checks that public contract deterministically.
+It rejects missing, repeated, misplaced, hidden, unordered, or unsupported visible
+structure. Completion checkboxes belong only to the Completion gate section. Ready
+pull requests must have every checkbox checked; drafts may retain unchecked work.
+The managed template never solicits execution identity,
+and authors plus independent review keep it out of free-form values. The validator is
+a positive grammar for public fields; it deliberately does not guess identities from
+an open-ended vocabulary of names or labels.
+
 At any point:
 
     processctl change status --change-id change-123 --json

{engineering_process-1.1.2 → engineering_process-1.2.0}/engineering_process/__init__.py

@@ -1,3 +1,3 @@
 """Agent-neutral engineering process."""
 
-VERSION = "1.1.2"
+VERSION = "1.2.0"

engineering_process-1.1.2/engineering_process/supervision.py → engineering_process-1.2.0/engineering_process/_supervisor_contract.py

@@ -1,14 +1,8 @@
-"""Portable foreground-task supervision.
-
-The public execution contract is deliberately platform-neutral.  Kernel-specific
-process containment lives in the selected backend and must not leak into consumer
-manifests, reports, or lifecycle code.
-"""
+"""Platform-neutral process supervision contract."""
 
 from __future__ import annotations
 
 from dataclasses import dataclass
-import os
 from pathlib import Path
 import subprocess
 from typing import Mapping, Protocol
@@ -62,18 +56,3 @@ class ProcessSupervisor(Protocol):
         *,
         grace_seconds: float,
     ) -> CleanupOutcome: ...
-
-
-def process_supervisor(*, platform_name: str | None = None) -> ProcessSupervisor:
-    """Select the sole platform adapter used by the execution layer."""
-
-    selected = os.name if platform_name is None else platform_name
-    if selected == "posix":
-        from ._supervisor_posix import POSIX_SUPERVISOR
-
-        return POSIX_SUPERVISOR
-    if selected == "nt":
-        from ._supervisor_windows import WINDOWS_SUPERVISOR
-
-        return WINDOWS_SUPERVISOR
-    raise OSError(f"unsupported process supervision platform: {selected}")

{engineering_process-1.1.2 → engineering_process-1.2.0}/engineering_process/_supervisor_posix.py

@@ -13,7 +13,7 @@ import sys
 import time
 from typing import Mapping
 
-from .supervision import CleanupOutcome, NATURAL_DRAIN_GRACE_MILLISECONDS
+from ._supervisor_contract import CleanupOutcome, NATURAL_DRAIN_GRACE_MILLISECONDS
 
 
 PR_SET_CHILD_SUBREAPER = 36

{engineering_process-1.1.2 → engineering_process-1.2.0}/engineering_process/_supervisor_windows.py

@@ -10,7 +10,7 @@ import threading
 from typing import Mapping
 
 from .helper_launch import isolated_helper_command
-from .supervision import CleanupOutcome
+from ._supervisor_contract import CleanupOutcome
 
 
 _UNSUPPORTED_SHELL_SUFFIXES = {".bat", ".cmd"}

{engineering_process-1.1.2 → engineering_process-1.2.0}/engineering_process/cli.py

@@ -28,6 +28,7 @@ from .lifecycle import (
     begin_implementation,
     finish_change,
     lifecycle_status,
+    process_improvement_signals,
     register_plan,
     start_change,
     start_review,
@@ -35,6 +36,10 @@ from .lifecycle import (
     verify_change,
 )
 from .project import load_project, readiness_summary
+from .production_engineering import (
+    validate_plan_assessments,
+    validate_review_assessments,
+)
 from .publication_compat import (
     branch_issues,
     commit_issues,
@@ -117,7 +122,15 @@ def command_lock_validate(args: argparse.Namespace) -> Result:
 
 def command_contract_validate(args: argparse.Namespace) -> Result:
     process_root = _process_root(args)
-    load_and_validate(args.path, args.kind, schema_root=schemas_root(process_root))
+    document = load_and_validate(
+        args.path,
+        args.kind,
+        schema_root=schemas_root(process_root),
+    )
+    if args.kind == "plan":
+        validate_plan_assessments(document, process_root)
+    elif args.kind == "review":
+        validate_review_assessments(document, process_root)
     return _result("contract validate", kind=args.kind, path=str(args.path)), 0
 
 
@@ -298,6 +311,7 @@ def command_change_review_start(args: argparse.Namespace) -> Result:
         "change review start",
         state,
         assignment=state["reviewAssignment"],
+        processSignals=process_improvement_signals(state),
         reportPath=f".process/runs/{args.change_id}/review-{state['cycle']}.json",
     ), 0
 

{engineering_process-1.1.2 → engineering_process-1.2.0}/engineering_process/contracts.py

@@ -21,6 +21,7 @@ CONTRACT_KINDS = (
     "plan",
     "process-graph",
     "process-lock",
+    "production-engineering",
     "project",
     "project-legacy",
     "receipt",