engineering-process 0.1.0__py3-none-any.whl

engineering_process-0.1.0.dist-info/METADATA

@@ -0,0 +1,387 @@
+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).

engineering_process-0.1.0.dist-info/RECORD

@@ -0,0 +1,69 @@
+engineering_process/__init__.py,sha256=sr6Y1EeuE2b1pxlPEuwPRjfQaJnNUH_Q0Fb_85cn0xE,60
+engineering_process/_download_worker.py,sha256=VAh_6pjObYCtoegj_IiE1Z8ARuzr5IZzbzmB4JF5Z8M,2565
+engineering_process/_supervisor_posix.py,sha256=je8soio5GexWyRHPzGTEF6CTcdal_oLywZdfOziZ5dk,5330
+engineering_process/_supervisor_windows.py,sha256=dJ8OJ_II42dEg4yLsCh3f7QFNUelI8huB4-ISbfJE-Q,4728
+engineering_process/_windows_job.py,sha256=IzDNFPFm77ho8sWb_xXN0Ox0-DOhoHL1hDpLlQLCxP4,15280
+engineering_process/bootstrap.py,sha256=pQnf7ah-qOJGEHObA_jloU-Guo4phSOiOZhSL398VR4,7688
+engineering_process/bundles.py,sha256=VNb_7h7uCoD3NRawzqc61fCQZy5Af8SeiN-x_j5kfDg,2934
+engineering_process/cli.py,sha256=t-yix6JtzwmD5QX_Qg-zJAPmgNFGh51e8RY70RcNgwY,33294
+engineering_process/contracts.py,sha256=RQcb1uLFiozd15eXBEyYQHTZp2-vv11cGyGsyjuAyic,48579
+engineering_process/distribution.py,sha256=ojT6JKH_Db2pYnKy8V03a0WQhRc6byfGpdqniWjQ0_Y,2880
+engineering_process/environment.py,sha256=pwt-w106s4pJ35A3GhqXglts2h8VaJgaa3R9M3936JE,26186
+engineering_process/helper_launch.py,sha256=czSsEY1MBmJJQlMdn4s3x5HujKUvaPCrXVPHS0_fvAg,1087
+engineering_process/lifecycle.py,sha256=nJpBIrwoKTJ-qiOVSF8sSJzgsgo65nAJ-QBdNyr6rTg,35152
+engineering_process/managed.py,sha256=Ea-QWYQ3Mw5m2ycMmR57z-z0T8eThNWWU5I89XaC7R8,3358
+engineering_process/markdown.py,sha256=aemVlHhimYJObKgRfMG5maofxDuN9TR5Q_0g2lZxQeI,2493
+engineering_process/publication.py,sha256=PHlZIVmBH3QsaddLPOq6yYyeWKT6jmzc4QbCY_4gotU,17406
+engineering_process/requirements-build.txt,sha256=W5ahs6tozL1WzaH31W6AS3rAUZS4Z2KzdjyEwTqSz-s,19
+engineering_process/requirements-dev.txt,sha256=rziqwu7-SipEhI-GjKOBdOwfcy0PiRtP3nKYiXtglc8,243
+engineering_process/requirements-runtime.txt,sha256=S0fPUsz89qUYqNK-IMKPicLALpH1dVYvx1walBrDscI,52
+engineering_process/runner.py,sha256=__yzxavL5xu5bGSvOUYNVLG5Jm8Ocxj8ygYoRTlOoYo,5946
+engineering_process/runtime.py,sha256=LN13oFAosXfxlSzNUM9-Lax4vDhfxLTP_tFvgsLbMoE,1881
+engineering_process/skills.py,sha256=S_c2pQh40pcJtmdO9ltakK1nXaFN3jz_1CdLmW-CJ7Q,4626
+engineering_process/supervision.py,sha256=8_giRZ9kltHdXmeLe5k-Pya9ShK1gswIZDFTYjDIHgM,1892
+engineering_process/syncing.py,sha256=NuX-KCQUenqQDrvNI2pU6COvD6x_wAcSswNQFMxYZIg,15156
+engineering_process/tooling.py,sha256=VII4aTyDGfwmyBMWziBNLPMEIftIRC7uCvhZgh9k4BE,33121
+engineering_process-0.1.0.data/data/share/engineering-process/bundles.json,sha256=p3HBmz1yFJ3oJ5BIRp62l5dnC0OhRY5ITw8pQ6M8tmA,816
+engineering_process-0.1.0.data/data/share/engineering-process/examples/change.json,sha256=DloBrj9xBbwmbtVKop3d_DlHfLVsm-bfvwGsOba3DaY,663
+engineering_process-0.1.0.data/data/share/engineering-process/examples/plan.json,sha256=QsTApNafkUcEf-yjztQbqBiYY94lxxnBC3N9lrsXT5s,842
+engineering_process-0.1.0.data/data/share/engineering-process/examples/project.json,sha256=D82oXdVqcH2trZnTX6bXTSHzQC1uuXgbDf_XbunGMvQ,1187
+engineering_process-0.1.0.data/data/share/engineering-process/examples/review.json,sha256=TG5bODNLJdcHv9vPA3eqH88-jvxlpPi8Dz_DW0y7L1k,866
+engineering_process-0.1.0.data/data/share/engineering-process/schemas/change.schema.json,sha256=MUqK6DwVCkyr8z7yfkTB6d-RD9Rn2DZQx5u1wKAWW6I,2555
+engineering_process-0.1.0.data/data/share/engineering-process/schemas/lifecycle.schema.json,sha256=_rO3LOqac1TJjwLE_4YQaQl7WyyXMFIP-i2z7q-ycXM,3750
+engineering_process-0.1.0.data/data/share/engineering-process/schemas/plan.schema.json,sha256=WFYFpIAaoOp2K10T0qNHwXTEiRklUptqQq9H1KFIReQ,3030
+engineering_process-0.1.0.data/data/share/engineering-process/schemas/process-lock.schema.json,sha256=DTrzvLkxmOtTDYJPCeg2kRcqsNkALcXq2s3l6sH8Q_g,918
+engineering_process-0.1.0.data/data/share/engineering-process/schemas/project.schema.json,sha256=MiWkI0cYYVUUeyCB2vFpTlLoQESbCAVLHCgK7um4irA,14414
+engineering_process-0.1.0.data/data/share/engineering-process/schemas/review.schema.json,sha256=6JgmV6DTU_awjAlCVZk0auPmKOmvsGDeX5SpKDdJR-0,4146
+engineering_process-0.1.0.data/data/share/engineering-process/schemas/reviewer-attestation.schema.json,sha256=iCZiBQwB1EOf3lWn1bu7aid1hFepu07NQClPVHnnPV4,1089
+engineering_process-0.1.0.data/data/share/engineering-process/schemas/verification.schema.json,sha256=_dt63ONZxE6wHrZrqZgRscNYmfTWxjtqQoHWCl8FepY,2729
+engineering_process-0.1.0.data/data/share/engineering-process/skills/assess-design/SKILL.md,sha256=5xwPCojPTpKz7i22AM_Bw3UcdTQsSv9m_-fHW6XM2Mw,1948
+engineering_process-0.1.0.data/data/share/engineering-process/skills/build-frontend/SKILL.md,sha256=hAtfCv84kXjHFqojc1wqpukUb7NG6kPej2vQXgTmZ_E,1810
+engineering_process-0.1.0.data/data/share/engineering-process/skills/build-frontend-foundation/SKILL.md,sha256=EDSJee7jj6SDEpbNI6uhsUuiqzdpg94pDkpNn-NElvA,1752
+engineering_process-0.1.0.data/data/share/engineering-process/skills/change-api/SKILL.md,sha256=rFf1VjkMuc3J6n8tJEdHXKlQlS9XSjbriqsazLc_oZM,1789
+engineering_process-0.1.0.data/data/share/engineering-process/skills/cross-repo-change/SKILL.md,sha256=-xbh0CFa-sNHP4npLghHJ0rNx5cTC_vm1S6Dwnzbdos,1809
+engineering_process-0.1.0.data/data/share/engineering-process/skills/define-change-contract/SKILL.md,sha256=WTs2cVdlLKIsmwLbrx_vzt2XU7wl8CwvDvo4NkJMm9k,1989
+engineering_process-0.1.0.data/data/share/engineering-process/skills/design-module/SKILL.md,sha256=JQf-ijVD-4ZF_HgqV5VtddycpDvpIya5UfiEBsuzJlU,1723
+engineering_process-0.1.0.data/data/share/engineering-process/skills/evolve-process/SKILL.md,sha256=CST0FwZGROos3caumjdAhaBq7418GXbN-9IRfc0PwJw,1657
+engineering_process-0.1.0.data/data/share/engineering-process/skills/finish-change/SKILL.md,sha256=-RS35B4RMpj4Znsg4BaKebNLb60tnWWO5tRsQoK7TaE,1561
+engineering_process-0.1.0.data/data/share/engineering-process/skills/govern-ui/SKILL.md,sha256=NwwFTyeKH4yZebSkqOWM08MMrfgyqTlLCnM2oUv0vWg,2041
+engineering_process-0.1.0.data/data/share/engineering-process/skills/implement-change/SKILL.md,sha256=70_eypofM5nbvqOojlCI8hG756LU6x02fJqSoxDyz74,2003
+engineering_process-0.1.0.data/data/share/engineering-process/skills/implement-module/SKILL.md,sha256=5ZzNrMlul5S_spcmYGNXBr72DY62j5IPAwbhak5YoNo,1566
+engineering_process-0.1.0.data/data/share/engineering-process/skills/implement-use-case/SKILL.md,sha256=gHhJB437Dh-P6eQjcRkBDihuQgQy3ssu219tEbE3hvA,1681
+engineering_process-0.1.0.data/data/share/engineering-process/skills/integrate-mcp/SKILL.md,sha256=oxZSXBoz2IugWwCV-Up7FyY5xxbVheWD5417GSztx_k,1882
+engineering_process-0.1.0.data/data/share/engineering-process/skills/maintain-docs/SKILL.md,sha256=5Ab-sGNQ66AkpSxjjk70BL_wJfPbXBL21YciB0Oj4GE,1617
+engineering_process-0.1.0.data/data/share/engineering-process/skills/plan-change/SKILL.md,sha256=9HfMNXrSD6cwMPDSCecPzL9AcYLlfkgW7Mcf4oSbziw,1628
+engineering_process-0.1.0.data/data/share/engineering-process/skills/publish-change/SKILL.md,sha256=T5dsFELT2Oam9wTirI5Tb9xVRSMDVcQ4loY8YIrHV3E,1738
+engineering_process-0.1.0.data/data/share/engineering-process/skills/review-change/SKILL.md,sha256=LoP-D6MJAJ1vL-aS8AutgJEDugW1RtURpW3yslf_Feo,2691
+engineering_process-0.1.0.data/data/share/engineering-process/skills/run-change/SKILL.md,sha256=WbPZ63vdp7cPTtucI8qstfXXNY5nYqcPgsWD6KJDqgw,2458
+engineering_process-0.1.0.data/data/share/engineering-process/skills/run-change/references/execution.md,sha256=Zo_38Bsc-1NH12Vc5sDYX6_39ps1r0dCBCiwN-OlM2U,4671
+engineering_process-0.1.0.data/data/share/engineering-process/skills/run-project-command/SKILL.md,sha256=u77FmChZ8O5mNXZJlgm_rNoBvLPJXtCogeZhxYsMSp0,3188
+engineering_process-0.1.0.data/data/share/engineering-process/skills/specify-use-case/SKILL.md,sha256=cxf-4qIL5EvlSDabtWWCcPBhM9HReeSt2P_uSEKhoe0,1806
+engineering_process-0.1.0.data/data/share/engineering-process/skills/verify-change/SKILL.md,sha256=KdMEtfFk1rYP7u2sFlzdy1cRCETc5l8GfvgVM_GPNq8,1737
+engineering_process-0.1.0.data/data/share/engineering-process/templates/AGENTS.process.md,sha256=nzfuMzAawpEZk5PJPNgLjfDsj_-eHorRra-XuqqkOlo,917
+engineering_process-0.1.0.data/data/share/engineering-process/templates/PULL_REQUEST_TEMPLATE.md,sha256=YHcPujaWXR6T5qY0NHavnW8oJ6rvqj4Yy45N7IEHErU,1077
+engineering_process-0.1.0.dist-info/licenses/LICENSE,sha256=Tm6UkBZiW25MSgs721n0XrIdhEYNpRpPbAjoKg4nfLc,1089
+engineering_process-0.1.0.dist-info/METADATA,sha256=2IuTxEbeHLY2bZFqEvjHX61v-p4J5r2FK9uToAjTHTY,19207
+engineering_process-0.1.0.dist-info/WHEEL,sha256=YVMoNqKzERt-wjUZwJ33xBGAwnFl-4cqbYkTtWa4itE,91
+engineering_process-0.1.0.dist-info/entry_points.txt,sha256=pq2B7N0N_GmwdZKLTSZC5CK30e71UQ1hgpvLCagrn_Q,60
+engineering_process-0.1.0.dist-info/top_level.txt,sha256=H4SsnAxJXndryC0y1hGHHPc2qswVIsEzgwbcCd___lM,20
+engineering_process-0.1.0.dist-info/RECORD,,

engineering_process-0.1.0.dist-info/WHEEL

@@ -0,0 +1,5 @@
+Wheel-Version: 1.0
+Generator: setuptools (84.0.0)
+Root-Is-Purelib: true
+Tag: py3-none-any
+

engineering_process-0.1.0.dist-info/entry_points.txt

@@ -0,0 +1,2 @@
+[console_scripts]
+processctl = engineering_process.cli:main

engineering_process-0.1.0.dist-info/licenses/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 engineering-process contributors
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

engineering_process-0.1.0.dist-info/top_level.txt

@@ -0,0 +1 @@
+engineering_process