Metadata-Version: 2.4
Name: engineering-process
Version: 0.1.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
Project-URL: Issues, https://github.com/phuongnse/engineering-process/issues
Project-URL: Repository, https://github.com/phuongnse/engineering-process.git
Classifier: Development Status :: 3 - Alpha
Classifier: Environment :: Console
Classifier: Operating System :: MacOS
Classifier: Operating System :: Microsoft :: Windows
Classifier: Operating System :: POSIX :: Linux
Classifier: Programming Language :: Python :: 3
Classifier: Programming Language :: Python :: 3 :: Only
Classifier: Topic :: Software Development :: Quality Assurance
Requires-Python: >=3.11
Description-Content-Type: text/markdown
License-File: LICENSE
Requires-Dist: markdown-it-py==4.2.0
Requires-Dist: mdurl==0.1.2
Requires-Dist: regex==2026.7.19
Provides-Extra: dev
Requires-Dist: attrs==26.1.0; extra == "dev"
Requires-Dist: build==1.5.0; extra == "dev"
Requires-Dist: colorama==0.4.6; os_name == "nt" and extra == "dev"
Requires-Dist: jsonschema==4.26.0; extra == "dev"
Requires-Dist: jsonschema-specifications==2025.9.1; extra == "dev"
Requires-Dist: packaging==26.3; extra == "dev"
Requires-Dist: pyproject_hooks==1.2.0; extra == "dev"
Requires-Dist: referencing==0.37.0; extra == "dev"
Requires-Dist: rpds-py==2026.6.3; extra == "dev"
Requires-Dist: typing-extensions==4.15.0; python_version < "3.13" and extra == "dev"
Dynamic: license-file

# Engineering Process

An agent-neutral, end-to-end engineering lifecycle. A consumer supplies project
policy and commands; this repository supplies the same specification, planning,
implementation, verification, independent-review, finding-loop, and completion
gates to every project.

The enforcement boundary has three parts:

1. Portable Agent Skills tell any compatible agent how to perform each phase.
2. `processctl` owns lifecycle state, transitions, immutable evidence, and exit codes.
3. The consumer's `AGENTS.md` and `.process/project.json` own domain policy and exact
   argument-array verification commands.

Publication conventions are distribution-owned as well: manual and automation branch
names, Conventional Commit subjects, PR titles, the managed PR-description structure,
structured requirement statuses, and draft-versus-ready semantics are validated by
`processctl publication ...`. Projects populate those sections with their own contract,
impact, risk, evidence, and review details and may append stronger domain checks.

Core semantics never name a model, agent product, orchestration API, or code-indexing
provider. An agent host or human workflow supplies an independent reviewer identity;
`processctl` rejects any reviewer actor or context used by the current implementation
cycle. If the host cannot attest separation, review remains blocked.

The core ships only the agent-neutral reviewer-attestation contract. Host-specific
launchers and model configuration are separate integrations and are never part of a
required process bundle.

Python 3.11 or newer and Git are required. Windows command containment requires
Windows 10 or Windows Server 2016 and newer so Job Object membership can be attached
atomically during process creation. Lifecycle state is stored under ignored
`.process/runs/`; completion, review, and verification are bound to a clean Git
checkpoint and workspace fingerprint.

## Execution architecture

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
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.

This task boundary intentionally separates finite commands from services and
interactive protocols. `processctl exec`, requirement probes, setup command actions,
and verification checks are finite foreground tasks. Detached Docker Compose stacks,
log followers, interactive shells, watchers, and stdio servers remain project-owned
commands outside this executor until a separate service or interactive lifecycle is
specified. They must not be placed in verification profiles or wrapped by
`processctl exec`.

## Consumer bootstrap

Add only project-owned configuration:

~~~text
project/
├── AGENTS.md
├── .github/
│   └── PULL_REQUEST_TEMPLATE.md
├── .gitignore             # includes .process/runs/
└── .process/
    └── project.json       # project profiles and lifecycle baseline
~~~

Install `processctl` from a tagged release and create a candidate manifest from
`examples/project.json` with the repository's real commands. Bootstrap the complete
standard in one command:

~~~text
python -m pip install "engineering-process==0.1.0"
processctl project init --project-root . --manifest project.json \
  --bundle core --bundle delivery --bundle product
processctl doctor --project-root .
~~~

`project init` validates the manifest, preflights ownership conflicts, writes the
lock, installs the managed `AGENTS.md` and pull-request contracts, adds the ignored
lifecycle-state path, and synchronizes the selected skills. It refuses to replace
differing project configuration or unmanaged skills unless the conflict is resolved
explicitly. `sync --check` and `doctor` detect drift in skills, the managed agent
contract, and the pull-request block. A consumer never authors or maintains process
skills locally.

The single project-manifest contract includes environment profiles, project-attested
read-only requirement probes, remediation, declarative managed-tool artifacts, and
optional setup actions. Use the same interface in every consumer:

~~~text
processctl doctor --project-root . --profile development
processctl setup --project-root . --profile development
processctl setup --project-root . --profile development --apply \
  --allow network --allow user-files --allow project-files
processctl exec --project-root . --profile development -- \
  python scripts/project.py local-dev
~~~

A portable tool is data, not a consumer-owned installer. Each project pins the
version and one immutable artifact contract per supported platform, then references
the tool from a `managed-tool` setup action:

~~~json
{
  "managedTools": [{
    "id": "sample-tool",
    "version": "1.2.3",
    "artifacts": [{
      "platform": "linux-glibc-x64",
      "url": "https://publisher.example/sample-tool-1.2.3.tar.gz",
      "checksum": "sha256:0000000000000000000000000000000000000000000000000000000000000000",
      "archiveFormat": "tar.gz",
      "stripComponents": 1,
      "maxDownloadBytes": 50000000,
      "maxExtractedBytes": 200000000,
      "maxFiles": 10000,
      "commands": {"sample-tool": "bin/sample-tool"}
    }]
  }],
  "setupActions": [{
    "id": "install-sample-tool",
    "kind": "managed-tool",
    "tool": "sample-tool",
    "timeoutSeconds": 600
  }]
}
~~~

The zero checksum above is a shape example only; a real manifest must contain the
publisher artifact's verified digest and declare every supported platform explicitly.

Schema-3 Windows command entries must resolve to native `.exe` applications. Batch
files are rejected because running `.cmd` or `.bat` requires a command shell. When a
publisher exposes a script launcher, bind the stable logical command to a verified
native runtime and a verified contained script instead. For example, a Windows Node
artifact can preserve the portable `npm` command without `cmd.exe`:

~~~json
{
  "commands": {
    "npm": {
      "executable": "node.exe",
      "script": "node_modules/npm/bin/npm-cli.js"
    }
  }
}
~~~

Managed artifact paths always use contained, relative, forward-slash syntax on every
host. Schema-1 and schema-2 project manifests remain readable for lifecycle history,
but a schema-2 Windows `.cmd` or `.bat` launcher is intentionally not executable by
the shell-free supervisor. Migrate that entry manually to schema 3 and bind it to the
publisher's trusted native runtime and contained script as above; a generic migrator
cannot safely infer either file or attest that the task is foreground-only.

The report still records the logical command such as `["npm", "ci"]`; the executor
uses the absolute managed application and script paths internally. Unqualified Windows
commands are resolved only from absolute PATH entries, so a same-named executable in
the project working directory cannot shadow a verified managed tool.

`doctor` executes only probes explicitly attested `readOnly: true` and never invokes
setup actions. A schema-3 environment contract must also attest `foregroundOnly: true`
for every process-managed task. The project owner remains responsible for those
attestations.
`setup` is plan-only unless `--apply` is present, computes
the full dependency-ordered action plan before execution, and refuses to run any
action until every declared mutation scope has been approved. Supported scopes are
`network`, `project-files`, `user-files`, and `host-configuration`. Commands are
argument arrays executed without a shell, with bounded output, timeout, exit status,
owned process-group/job cleanup, and command digest evidence. `exec` runs an
ad-hoc project command only after the selected environment passes and injects paths
for verified managed tools. After applying a plan, processctl reruns the original
probes; an installer exit code alone never proves readiness.

The distribution owns detection, planning, bounded execution, HTTPS acquisition,
size limits, checksum verification, safe archive extraction, atomic user-local tool
installation, and exact managed command binding/PATH injection. A consumer owns only
declarative environment
data: exact probes, tool versions and per-platform artifacts, immutable checksums,
project-native dependency commands, dependency edges, and remediation. Project source
does not carry a generic downloader, archive installer, doctor, or setup lifecycle.
Host prerequisites with no safe automated setup action stay blocking.

Probe `readOnly`, foreground-only execution, and command-action mutation scopes are
project-owner attestations, not an operating-system sandbox: `processctl` cannot infer
arbitrary subprocess side effects. Commands must not daemonize, start a detached
session, or leave background work behind. The runner owns a POSIX process group and a
Windows Job Object, but no portable POSIX primitive can contain a deliberately detached
process. Managed-tool actions are stronger—the distribution constrains them to
HTTPS, declared size/checksum/archive/path boundaries and derives their approvals as
`network` plus `user-files`. Use a command action only for project-native package
managers or domain preparation that cannot be represented by the managed-tool
primitive, and declare every possible scope truthfully. New consumers use
project-manifest schema 3. Schema 1 (without an environment contract) and schema 2
(the original environment contract) remain readable for backward compatibility; they
are not relabeled as newer shapes. A consumer upgrades explicitly to schema 3 to
attest foreground-only task execution and use managed script bindings. New integrations
receive the complete environment contract instead of creating a project-local doctor
or setup lifecycle.

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
`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
unpublished development iteration.

During process development, pass
`--process-root /path/to/engineering-process`; consumer manifests never store that
local path.

`project.json.lifecycle.requiredProfiles` is the minimum evidence for every change.
Individual change contracts may add profiles but cannot remove the baseline.
Agents enter non-trivial delivery through the synchronized `run-change` skill; phase
skills are internal owners, not a workflow each project must reconnect.

## Canonical lifecycle

Create a change contract from `examples/change.json` and a plan from
`examples/plan.json`. The plan's `contractDigest` is returned by `change start`.

~~~text
processctl change start --contract change.json \
  --actor worker --context worker-session --actor-kind agent

processctl change plan --change-id issue-123 --plan plan.json \
  --actor worker --context worker-session --actor-kind agent

processctl change implement --change-id issue-123 \
  --actor worker --context worker-session --actor-kind agent

processctl change verify --change-id issue-123 --profile development \
  --actor worker --context worker-session --actor-kind agent

processctl change verify --change-id issue-123 --profile review \
  --actor worker --context worker-session --actor-kind agent
~~~

After the phase becomes `verified`, a separate reviewer context registers its
assignment:

~~~text
processctl change review start --change-id issue-123 \
  --actor reviewer --context isolated-review-session --actor-kind agent \
  --method isolated-context --attested-by agent-host \
  --attestation-evidence "Host-created isolated read-only context"

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:

~~~text
processctl change finish --change-id issue-123 \
  --actor worker --context worker-session --actor-kind agent
processctl change status --change-id issue-123
~~~

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.

Open and deferred findings remain completion-blocking until a later review records
them as resolved or false-positive with evidence. Schema-1 lifecycle state is loaded
through a fail-closed migration that replays immutable review artifacts to reconstruct
pending findings before any transition is allowed.

Completion does not imply commit creation, push, merge, release, or deployment.
Those remain separately authorized project workflows.

## Publication contract

Validate common metadata before creating or updating a review object:

~~~text
processctl publication validate-branch --branch feat/short-description
processctl publication validate-commit --subject "feat(scope): describe the change"
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
~~~

Manual branches use `{type}/{kebab-description}`. Automation uses the provider-neutral
`automation/{owner}/{description}` namespace. Commit subjects and PR titles use
Conventional Commit syntax and are limited to 72 characters. Draft PRs may retain
explicitly pending checklist items; every ready PR, including automation, must satisfy
them. The managed template owns the ordered shared sections and immutable standard
checklist meaning. An optional extension after its closing marker uses only
`## Project-specific requirements` plus one-line
`**Project-specific: Label**` checklist items; arbitrary headings, prose, HTML, and
code fences are rejected, and reserved core-policy phrases are rejected anywhere in
an extension item. These checks prevent structural shadowing; independent review
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.

## Trust boundary

The CLI proves structural separation: reviewer actor id and context id must both be
unused by implementation, and the review must match the verified checkpoint. The
agent host or human organization owns the truth of the identity attestation. A host
adapter should create a read-only isolated context, pass stable identities to
`change review start`, and preserve its evidence. Self-asserted separation without a
host or human attestation does not satisfy the process.

`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.

## Distribution contracts

- `project.json` declares baseline profiles and exact argument-array checks.
- `process.lock` pins the process version, selected skills, and a digest covering the
  runtime, canonical exact runtime/build/development dependency locks, schemas,
  templates, bundle catalog, and
  complete selected skill resources. Startup fails when installed runtime dependency
  versions differ from that lock.
- Versioned JSON schemas define change, plan, verification, review, lifecycle, and
  completion-related artifacts.
- Project commands run without a shell and inherit the caller environment. Never put
  secrets in manifests, arguments, or reports.
- Consumer skill roots are distribution-owned: unmanaged `SKILL.md` files or catalog
  files fail `sync` and `doctor`. Project-specific policy belongs in `AGENTS.md`,
  product contracts, source, and the manifest's command bindings.
- Host-specific launchers, agent role files, and model settings are optional external
  integrations. They are neither bundled into the core nor required in consumer
  repositories.
- The managed pull-request template and publication validators are shared process
  policy. Consumer repositories may append project-specific requirements after the
  managed block but do not copy or redefine the common convention.

## Development

~~~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 processctl.py skills validate --root .agents/skills
.venv/bin/python processctl.py digest
~~~

Version 0.x remains a compatibility pilot. A 1.0 release requires publishing the CLI,
running consumer CI through the published artifact, and completing forward tests on
representative agent hosts. Portable evaluation fixtures live in `evals/cases.json`.
Maintainer release steps and the secretless PyPI publisher identity are defined in
[`RELEASING.md`](https://github.com/phuongnse/engineering-process/blob/main/RELEASING.md).
