@research-engineering/agentic-proofkit 0.1.136

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (30) hide show
  1. package/ADOPTION.md +198 -0
  2. package/AGENTS.md +160 -0
  3. package/BACKLOG.md +217 -0
  4. package/CONTRIBUTING.md +70 -0
  5. package/LICENSE +21 -0
  6. package/NON_CLAIMS.md +45 -0
  7. package/README.md +50 -0
  8. package/SECURITY.md +52 -0
  9. package/dist/agentic-proofkit +36 -0
  10. package/dist/platform/darwin-arm64/agentic-proofkit +0 -0
  11. package/dist/platform/darwin-x64/agentic-proofkit +0 -0
  12. package/dist/platform/linux-arm64/agentic-proofkit +0 -0
  13. package/dist/platform/linux-x64/agentic-proofkit +0 -0
  14. package/docs/proofkit-contract-map.md +148 -0
  15. package/docs/release-process.md +228 -0
  16. package/docs/specs/proofkit-consumer-infra-retirement/overview.md +62 -0
  17. package/docs/specs/proofkit-consumer-infra-retirement/requirements.v1.json +283 -0
  18. package/docs/specs/proofkit-package-boundary/overview.md +43 -0
  19. package/docs/specs/proofkit-package-boundary/requirements.v1.json +176 -0
  20. package/docs/specs/proofkit-receipt-authority/overview.md +35 -0
  21. package/docs/specs/proofkit-receipt-authority/requirements.v1.json +121 -0
  22. package/docs/specs/proofkit-spec-proof-core/overview.md +98 -0
  23. package/docs/specs/proofkit-spec-proof-core/requirements.v1.json +448 -0
  24. package/docs/specs/proofkit-supply-chain-quality/overview.md +95 -0
  25. package/docs/specs/proofkit-supply-chain-quality/requirements.v1.json +260 -0
  26. package/package.json +71 -0
  27. package/proofkit/cli-contract.v1.json +1601 -0
  28. package/proofkit/receipt-producer-policy.json +49 -0
  29. package/proofkit/requirement-bindings.json +1914 -0
  30. package/proofkit/witness-plan.json +1226 -0
package/ADOPTION.md ADDED
@@ -0,0 +1,198 @@
1
+ # Adoption Contract
2
+
3
+ `agentic-proofkit` is a reusable CLI and JSON infrastructure dependency for
4
+ agentic proof workflows. Consuming repositories may use it only as a mechanics
5
+ owner: it validates, renders, plans, and packages explicit caller-owned records.
6
+ It does not own product meaning, native witness execution, proof freshness,
7
+ merge admission, rollout, deployment, or production readiness.
8
+
9
+ Formal dependency-readiness predicate:
10
+
11
+ ```text
12
+ external dependency ready :=
13
+ exact package artifact identity
14
+ and package gate evidence
15
+ and installed CLI binary consumer contract
16
+ and explicit rollback path
17
+ and channel-specific authority
18
+ ```
19
+
20
+ Source presence, an open pull request, a dry-run package artifact, or a GitHub
21
+ Release archive is not enough to satisfy this predicate.
22
+
23
+ ## Distribution Channels
24
+
25
+ Public npm is the primary package-manager channel for JavaScript, TypeScript,
26
+ Bun, and other Node-package consumers. The npm package identity is
27
+ `@research-engineering/agentic-proofkit`; the installed CLI binary remains
28
+ `agentic-proofkit`. PyPI is the Python/uv channel after its own Trusted
29
+ Publisher and post-publish registry identity are admitted. GitHub Release
30
+ assets are archive and provenance lookup, not package-manager dependency
31
+ authority.
32
+
33
+ Stable authority channel ids:
34
+
35
+ | Channel | Authority owner | Non-claims |
36
+ |---|---|---|
37
+ | `tarball_pilot` | exact local root package tarball produced by the package artifact gate | source checkout, registry release, consumer rollout |
38
+ | `registry_release` | public npm registry identity captured by the release workflow for tag `v<version>` | consumer dependency admission, native witness pass, rollout |
39
+ | `python_wheel_candidate` | platform wheels produced from the same Go CLI candidate | PyPI registry authority, consumer install proof |
40
+ | `pypi_registry_release` | PyPI JSON identity captured after publish or exact existing-byte match | consumer install proof, rollout |
41
+ | `github_release_archive` | GitHub Release asset inventory, checksums, SBOM, and retained release metadata | package-manager dependency authority |
42
+
43
+ Registry publication modes are:
44
+
45
+ | Mode | Meaning | Non-claim |
46
+ |---|---|---|
47
+ | `published_by_workflow` | the current release workflow published the candidate bytes through the admitted provider path | provider UI settings are not proven by the local report alone |
48
+ | `existing_byte_match` | the registry version already existed and byte-matched the candidate artifact | current-run publisher provenance |
49
+ | `mixed` | some files were current-run publications and others were existing byte matches | uniform provenance for every file |
50
+
51
+ When a channel claims Trusted Publisher or OIDC publication, retained evidence
52
+ must name the provider, registry, project name, repository, exact tag workflow
53
+ ref, publisher job, environment, and package identity.
54
+
55
+ ## One-Dependency Infrastructure Model
56
+
57
+ Consumers should not copy Proofkit verifier logic. They should keep only
58
+ caller-owned semantic inputs and route reusable mechanics through the CLI:
59
+
60
+ ```text
61
+ consumer structured records
62
+ -> proofkit validation and reports
63
+ -> on-demand human rendering
64
+ -> bounded agent slices or envelopes
65
+ -> caller-owned native witnesses and receipts
66
+ ```
67
+
68
+ Proofkit may provide:
69
+
70
+ - schemas and strict JSON admission for caller-owned records;
71
+ - immutable canonical projections after admission;
72
+ - deterministic reports, view models, and loopback-only browser serving;
73
+ - requirement source, proof binding, source-set, test inventory, coverage,
74
+ impact, selective planning, receipt, release, adoption, and scaffold
75
+ primitives;
76
+ - bounded agent guidance packets that state required inputs, blockers,
77
+ non-claims, and escalation points.
78
+
79
+ The consumer still provides:
80
+
81
+ - product requirement sentences and owners;
82
+ - proof-binding content and command policy;
83
+ - native witnesses and their execution semantics;
84
+ - CI producer admission policy and receipt freshness;
85
+ - credential approval, merge admission, rollout, and rollback decisions.
86
+
87
+ ## Imperfect Repository Adoption
88
+
89
+ Proofkit is not limited to already-perfect repositories. Its generic
90
+ responsibility in a messy or modernizing repository is transition discipline.
91
+ It can report gaps, stale local proof owners, duplicate proof routes, orphan
92
+ tests, candidate boundaries, and migration questions. It must keep candidate
93
+ boundaries advisory until the consuming repository promotes them into stable
94
+ requirement records and proof bindings.
95
+
96
+ Safe modernization loop:
97
+
98
+ ```text
99
+ caller-provided observations over code, tests, and docs
100
+ -> proofkit inventory, gap report, and agent guidance
101
+ -> owner-selected semantic boundary
102
+ -> stable requirement records
103
+ -> proof-binding contract records
104
+ -> native tests or tools that falsify the requirements
105
+ -> contract tests and validators for proof infrastructure
106
+ -> admitted receipts from caller-approved producers
107
+ -> stronger enforcement mode
108
+ ```
109
+
110
+ Adoption modes:
111
+
112
+ | Mode | Use case | Proofkit role | Consumer decision |
113
+ |---|---|---|---|
114
+ | `observe` | unknown or messy repository area | inventory, gaps, questions, non-blocking guidance | whether the area is worth specifying |
115
+ | `warn` | provisional boundary | visible drift and missing-binding warnings | whether warnings block a PR |
116
+ | `enforce-touched` | stabilized touched boundary | fail closed for changed admitted owners | touched-scope completeness and receipts |
117
+ | `enforce-all` | fully admitted scope | fail closed for all admitted blocking owners | full coverage claim and rollout |
118
+
119
+ Candidate boundaries in `observe` and `warn` are advisory. Enforcement modes
120
+ fail closed while candidate boundaries remain unresolved because enforcement
121
+ requires owner-admitted requirements and proof bindings.
122
+
123
+ ## Requirement, Contract, And Test Order
124
+
125
+ The durable semantic source is the repository-owned requirement package:
126
+ human context in `overview.md` plus machine-admissible `requirements.v1.json`
127
+ records. The overview explains context; it does not create uncited durable
128
+ truth.
129
+
130
+ Proof bindings are verification-route contracts. They answer which scenario,
131
+ witness, command, environment class, and receipt policy can falsify or support
132
+ a requirement. Native tests and tools own executable verification procedures
133
+ and observed result semantics. Contract tests and validators prove the proof
134
+ infrastructure itself is coherent.
135
+
136
+ Formal authority order:
137
+
138
+ ```text
139
+ Requirement source owns meaning.
140
+ Proof binding owns verification route.
141
+ Native test or tool owns executable falsifier.
142
+ Contract test owns infrastructure consistency.
143
+ Receipt owns recorded run facts and provenance.
144
+ Merge policy owns admission.
145
+ ```
146
+
147
+ Logical creation order for an accepted invariant:
148
+
149
+ 1. Create or update the stable `REQ-*` record.
150
+ 2. Create or update the proof-binding contract that maps the requirement to
151
+ witness obligations, command ids, environment class, and receipt class.
152
+ 3. Add or update native tests or tools that can falsify the requirement.
153
+ 4. Add or update Proofkit contract tests only when the proof infrastructure
154
+ itself changed.
155
+ 5. Admit receipts only from caller-approved producers.
156
+
157
+ Tests are not primary semantic authority. A test can prove an invariant only
158
+ when the requirement and proof-binding route make the tested obligation
159
+ explicit. Some high-level context can remain explanatory, but durable
160
+ `must`, `shall`, `guarantee`, or readiness claims must resolve to stable
161
+ requirement records or be rejected by the consuming repository's policy.
162
+
163
+ ## Rendering And Browser Views
164
+
165
+ Rendered HTML, Markdown, lookup graphs, and browser views are presentation
166
+ products. They should be generated on demand from explicit caller-owned inputs
167
+ unless a consumer explicitly admits a small tracked artifact with a freshness
168
+ gate.
169
+
170
+ Hierarchical rendering must use explicit input:
171
+
172
+ ```text
173
+ meta spec
174
+ -> module spec
175
+ -> optional submodule spec
176
+ -> presentation-only tree/view/export
177
+ ```
178
+
179
+ Proofkit may render this tree, filter IDs, show linked test scenarios, or
180
+ export Markdown/HTML. It must not infer the hierarchy from ambient paths or make
181
+ rendered output canonical truth.
182
+
183
+ ## Agent Guidance
184
+
185
+ Machine-facing reports should provide bounded prompts for coding agents when
186
+ that reduces ambiguity. A prompt-like action must identify:
187
+
188
+ - observed fact;
189
+ - uncertainty;
190
+ - owner or escalation target;
191
+ - exact files, ids, or selectors to inspect;
192
+ - candidate action;
193
+ - proof command or missing witness;
194
+ - non-claim that prevents the guidance from becoming semantic authority.
195
+
196
+ Agents must stop instead of guessing when ownership, proof freshness, producer
197
+ admission, native witness execution, or merge admission is outside Proofkit's
198
+ authority.
package/AGENTS.md ADDED
@@ -0,0 +1,160 @@
1
+ # agentic-proofkit Agent Instructions
2
+
3
+ This file is the repository coding-agent entrypoint for `agentic-proofkit`.
4
+
5
+ Scope: repository root unless a nearer nested `AGENTS.md` exists. A nested
6
+ entrypoint may refine local build or ownership rules, but it must not weaken
7
+ root safety, proof, release, or secret-handling rules.
8
+
9
+ Formal logic is the basis for every analysis, conclusion, decision, and
10
+ implementation action in this repository.
11
+
12
+ ## Authority Precedence
13
+
14
+ Use this order when instructions or evidence conflict:
15
+
16
+ 1. system and developer instructions of the current execution environment;
17
+ 2. safety, security, legal, privacy, and secret-handling constraints;
18
+ 3. explicit user instructions for the current task;
19
+ 4. nearest scoped `AGENTS.md`;
20
+ 5. this repository authority model;
21
+ 6. `README.md` as a human overview only;
22
+ 7. `BACKLOG.md` for current completion criteria, open work, and blocked claims;
23
+ 8. `ADOPTION.md`, `NON_CLAIMS.md`, `docs/proofkit-contract-map.md`, and
24
+ `docs/specs/*` as owner surfaces for their stated boundaries;
25
+ 9. imported source files, tests, package metadata, workflows, and
26
+ machine-readable contracts as owners for their exact behavior after they
27
+ exist in this repository;
28
+ 10. generated artifacts, registry output, CI logs, model output, chat memory,
29
+ issue text, and pull-request text as evidence only after owner admission.
30
+
31
+ If owner surfaces conflict, preserve safety, identify the contradiction, and
32
+ fix or report it. Do not silently choose the more convenient source.
33
+
34
+ ## Current Imported Surface
35
+
36
+ The repository is in a staged public cutover. Treat only files present in this
37
+ repository as authority for their exact behavior.
38
+
39
+ Imported source files, tests, package metadata, workflows, machine-readable
40
+ contracts, and specifications own their bounded surfaces after the pull request
41
+ that imports them has been reviewed and merged. Absent layers are non-claims.
42
+
43
+ Do not infer package publication, public-source provenance, provider-side
44
+ security ingestion, branch protection, Trusted Publisher, rollout, deployment,
45
+ or production readiness from source presence alone. Those claims require their
46
+ own release, provider, or deployment evidence.
47
+
48
+ ## Deterministic Start
49
+
50
+ 1. If the task names a concrete path, read that path first.
51
+ 2. If the request is clear, do not ask whether to resume previous work.
52
+ 3. If the request is ambiguous and strong unfinished-work signals exist,
53
+ inspect the worktree state and ask whether to resume.
54
+ 4. Use `BACKLOG.md` for current completion state and open work.
55
+ 5. Load one primary owner surface for the task. Load a second owner surface only
56
+ when the task clearly crosses another boundary.
57
+ 6. Stop context loading once the owner boundary, allowed mutation, proof path,
58
+ and closeout requirements are known.
59
+
60
+ ## Repository Invariants
61
+
62
+ - Proofkit stays generic. Do not add consuming-repository product policy,
63
+ topology-specific assertions, rollout decisions, or native witness execution
64
+ authority.
65
+ - The intended public contract is the CLI plus JSON input/output, exit codes,
66
+ package metadata, and shipped contract records after those surfaces are
67
+ imported.
68
+ - Caller-owned input is untrusted until admitted into canonical immutable
69
+ records. Code must not validate one representation and later reread mutable
70
+ caller input for policy, route, proof, persistence, or report decisions.
71
+ - Rendered HTML, Markdown, agent envelopes, and generated reports are derived
72
+ products. They are not authority unless a consuming repository explicitly
73
+ admits a tracked artifact with freshness checks.
74
+ - Current-build Proofkit output may provide advisory self-consistency, but
75
+ merge-critical proof must not depend only on the build being proven.
76
+ - New commands, files, specs, or docs are admitted only when they own a named
77
+ invariant, reusable algorithm, public contract, anti-corruption boundary, or
78
+ documented adoption or release obligation.
79
+ - Architecture documents, ADRs, and roadmaps are admissible only when a
80
+ deterministic requirement, machine contract, test, shipped operational guide,
81
+ or backlog row cannot express the same current authority with lower token
82
+ cost. They must name owner, scope, proof path, non-claims, and retirement or
83
+ supersession condition.
84
+
85
+ ## Security And Trust Boundaries
86
+
87
+ - Do not commit, print, log, summarize, or store secrets in docs, reports,
88
+ prompts, URLs, argv, fixtures, generated artifacts, or package metadata.
89
+ - Missing credentials, private source visibility, unavailable live services, or
90
+ blocked registry/provenance preconditions are `blocked` or `unverified`, not
91
+ `passed`.
92
+ - Local artifacts, registry output, release assets, CI receipts, and provider
93
+ dashboards are distinct evidence classes. Do not treat one as another unless
94
+ an owner surface defines the implication.
95
+ - Local, dry-run, generated, advisory, registry, provider, live, credentialed,
96
+ rollout, and production evidence classes do not imply each other unless an
97
+ owner-approved proof explicitly defines that implication.
98
+ - Trusted Publisher or OIDC release claims must name the workflow, source ref,
99
+ package, registry, environment, and post-publish registry identity.
100
+
101
+ ## Git And Worktree Safety
102
+
103
+ - Inspect worktree state before modifying files.
104
+ - Never revert user or other-agent changes unless explicitly requested.
105
+ - Do not use destructive version-control operations unless the user clearly
106
+ requested them or a repository owner surface defines a safe path.
107
+ - Use conventional commits.
108
+ - Keep changes owner-scoped and proof-scoped.
109
+ - Do not commit build artifacts, package tarballs, caches, local credentials,
110
+ or generated proof residue unless a release owner explicitly admits the
111
+ artifact.
112
+
113
+ ## Proof And Gates
114
+
115
+ Use the narrowest owner-valid proof first, then the current closeout gate for
116
+ the imported surface.
117
+
118
+ For public contract-only changes:
119
+
120
+ ```bash
121
+ git diff --check
122
+ ```
123
+
124
+ For runtime, package, CLI, workflow, or specification changes:
125
+
126
+ ```bash
127
+ npm run check
128
+ ```
129
+
130
+ Use narrower owner-valid gates first when iterating, then run the closeout gate
131
+ against the final committed object before push or merge whenever the change is
132
+ publishable.
133
+
134
+ Skipped gates must state the exact blocker and must not be reported as success.
135
+
136
+ ## Decision Protocol
137
+
138
+ Every non-trivial design or implementation decision should answer:
139
+
140
+ ```text
141
+ problem:
142
+ chosen owner boundary:
143
+ rejected lower-cost alternative:
144
+ proof invariant:
145
+ non-claims:
146
+ rollback or overturn condition:
147
+ why this avoids accidental complexity:
148
+ why this avoids premature over-decomposition:
149
+ ```
150
+
151
+ Add a durable rule only when it closes a confirmed repeatable weakness with a
152
+ known owner, trigger, proof path, and lower-cost alternative analysis.
153
+
154
+ ## Closeout Contract
155
+
156
+ Before stopping, report changed surfaces, proof gates run, skipped gates and
157
+ blockers, residual risk, explicit non-claims, and next action only if work
158
+ remains. For non-trivial changes, include a retro finding or `none`. For
159
+ repeated or systemic failures, also state the falsified invariant, correction
160
+ owner, and proof against recurrence.
package/BACKLOG.md ADDED
@@ -0,0 +1,217 @@
1
+ # Proofkit Backlog
2
+
3
+ This file is the canonical work ledger for completing the public
4
+ `research-engineering/agentic-proofkit` cutover. It tracks open work and blocked
5
+ claims. It is not a CLI manual, proof registry, or historical release log.
6
+
7
+ ## Completion Criteria
8
+
9
+ Proofkit can be called complete as an organization-neutral reusable toolkit
10
+ only when these criteria are satisfied or explicitly retired by owner decision:
11
+
12
+ 1. **Public source provenance is admitted.** A release is produced from this
13
+ public source repository and records source, tag, package, registry, and
14
+ release evidence.
15
+ 2. **Public npm release is admitted.** A versioned release publishes or
16
+ exact-byte-matches the root package, records post-publish npm identity,
17
+ verifies root-only installation, proves JSON CLI ABI from the installed
18
+ package, and documents rollback.
19
+ 3. **Optional PyPI channel is admitted before it is claimed.** Python/uv wheels
20
+ are candidate evidence until PyPI Trusted Publisher and post-publish PyPI
21
+ registry identity are proven.
22
+ 4. **Browser rendering is released.** Requirement source, proof, coverage, and
23
+ spec-tree views are consumable through CLI rendering and loopback-only
24
+ serving without requiring generated HTML in consumer repositories.
25
+ 5. **Repository identity is organization-neutral.** Package metadata, README,
26
+ agent entrypoint, docs, workflows, tests, and examples avoid organization-
27
+ or consumer-specific authority.
28
+ 6. **At least one consumer migration is proven from the public package.** A
29
+ consuming repository replaces local or vendored Proofkit access with the
30
+ public package, smokes the installed binary, records rollback, and keeps
31
+ product semantics local.
32
+ 7. **Second-consumer reuse is proven before broad reuse claims.** A second
33
+ topology adopts one stable module in observe or warn mode with explicit
34
+ caller-owned inputs.
35
+ 8. **Agent guidance is usable.** Reports provide bounded envelopes that name
36
+ what to inspect, who owns the decision, which proof route applies, what is
37
+ omitted, and what escalation is required.
38
+ 9. **Gradual adoption is usable for imperfect repositories.** A repository can
39
+ scaffold starter records, define owner-reviewed requirements, bind proofs,
40
+ run selective checks, and promote enforcement only after explicit owner
41
+ approval.
42
+ 10. **Self-hosting avoids circular proof.** Current-build Proofkit output may
43
+ provide advisory self-consistency, but merge-critical proof must rely on
44
+ native package gates, admitted CI producer policy, a prior release, or a
45
+ minimal bootstrap verifier.
46
+ 11. **Release-size changes are evidence-gated.** Platform-binary splitting,
47
+ OCI, Homebrew, or Go module distribution is admitted only when measured
48
+ consumer need outweighs added registry and adoption complexity.
49
+ 12. **Generic authority invariants are upstream-owned.** Requirement-binding
50
+ identity, test-inventory identity, report-shape admission, and other
51
+ cross-repository mechanics live in Proofkit before consumers retire
52
+ duplicate local checks.
53
+ 13. **Hierarchical spec rendering is explicit-input and presentation-only.**
54
+ Meta, module, and submodule spec chains can be rendered or exported from a
55
+ caller-owned tree without implicit repository scanning or generated-output
56
+ authority.
57
+
58
+ ## Current Cutover State
59
+
60
+ | Status | ID | Scope | Completion condition |
61
+ |---|---|---|---|
62
+ | DONE | IMPORT-01 | Public project contract | Initial public README, license, contribution, security, and source-hygiene boundaries were admitted. |
63
+ | DONE | IMPORT-02 | Deterministic kernel primitives | Core Go admission, stable JSON, digest, report, path, release-platform, and package helper primitives were imported with tests. |
64
+ | DONE | IMPORT-03 | CLI command and release proof surface | CLI registry, command families, package/release tools, npm/PyPI wrapper surfaces, specs, proofkit JSON, and workflows were imported with local `npm run check`. Provider CI, protected-branch, registry, and release evidence remain separate open proof classes. |
65
+ | DONE | IMPORT-04 | Adoption and backlog owner surfaces | Public-ready adoption and backlog routing were added without stale private release facts or consumer-specific claims. |
66
+ | DONE | IMPORT-05 | Historical design and plan cleanup | Durable claims from pre-cutover design and implementation-plan work are represented by deterministic specs, proof bindings, tests, package-public docs, or open backlog rows. No source-repository design documents or implementation plans are retained as current authority. |
67
+ | DONE | IMPORT-06 | Remaining source-local code delta audit | Non-document source comparison found no old source file missing from the public source tree. Old source bytes remain candidate evidence only and are not imported over current hardening. |
68
+ | DONE | RELEASE-01 | Public source release | `v0.1.135` was published from this public repository through npm Trusted Publisher, post-publish npm registry identity was captured, root-only installed-package proof passed, and GitHub Release assets were published. PyPI publication and GitHub artifact attestations were skipped by explicit optional-channel policy and are not claimed. |
69
+ | OPEN | RELEASE-02 | Scoped npm package identity | Source is staged for `@research-engineering/agentic-proofkit@0.1.136` while preserving the `agentic-proofkit` CLI binary and Python package identities. Completion requires scoped npm Trusted Publisher configuration, a `v0.1.136` release from public source, post-publish scoped npm registry identity, root-only installed-package JSON CLI ABI proof, and an explicit compatibility or deprecation disposition for the unscoped npm package. |
70
+ | DONE | SECURITY-01 | Provider security settings | Repository is public with collaborator-only PR creation, public issues, squash-only merges, branch protection on `main`, strict required CI, CodeQL, OSV source advisory scanning, Scorecard, Dependabot security updates, secret scanning, and push protection. Non-provider secret patterns and validity checks remain unavailable or disabled under the current provider plan and are not claimed. |
71
+ | DONE | CONSUMER-01 | Public-package consumer proof | A private first consumer repository consumed exact public npm `agentic-proofkit@0.1.134` through its repository-owned external-consumer gate. The proof installed the package into an isolated temporary consumer, matched the admitted tarball integrity and shasum, proved lockfile resolution was not workspace based, ran installed CLI `self-check`, `witness-plan`, and `release-authority`, proved rollback by removing the dependency from the temporary lockfile, and preserved consumer-owned native witness authority. |
72
+ | DONE | CONSUMER-02 | Second-consumer pilot | A private topology-distinct Python/FastAPI consumer module was run through explicit-input warn-mode `gradual-adoption-guidance` and `--agent-envelope` pilot records. Proofkit admitted the caller-owned route, reported one advisory candidate boundary, reported two missing proof-binding rule IDs as warnings, emitted route/bind/modernize/verify/promote agent actions, and kept enforcement blocked until consumer owners admit stable requirements and proof bindings. No generic Proofkit blocker was confirmed. |
73
+
74
+ ## Release Evidence
75
+
76
+ `RELEASE-01` was admitted on 2026-07-03 from public repository
77
+ `research-engineering/agentic-proofkit` at commit
78
+ `2bbc36607734589f9e49191b4dc03eb37c65115b` and tag `v0.1.135`.
79
+
80
+ Provider run:
81
+
82
+ ```text
83
+ https://github.com/research-engineering/agentic-proofkit/actions/runs/28677195127
84
+ ```
85
+
86
+ The release workflow completed successfully. It ran the release candidate
87
+ package gate, publish readiness, npm Trusted Publisher publish, post-publish
88
+ registry capture, root-only installed-package JSON CLI ABI proof, final release
89
+ metadata generation, and GitHub Release asset publication. The npm registry now
90
+ reports `agentic-proofkit@0.1.135` with repository URL
91
+ `git+https://github.com/research-engineering/agentic-proofkit.git`,
92
+ tarball
93
+ `https://registry.npmjs.org/agentic-proofkit/-/agentic-proofkit-0.1.135.tgz`,
94
+ integrity
95
+ `sha512-GrLDm3P67JeWiEHCO5m/y1KiJ8hUSzZdQk7rM/Vgrqx3gphc21PQO27HwODFUDp4Gb62l1FpJ8v6b4i7dfY43A==`,
96
+ shasum `41722c3fa35dfa7cdea3d78e2aa940fb7d5cbcf3`, and license `MIT`.
97
+
98
+ The npm Trusted Publisher relationship for `agentic-proofkit` was moved from
99
+ the old source repository to GitHub Actions repository
100
+ `research-engineering/agentic-proofkit`, workflow file `release.yml`,
101
+ environment `npm-production`. PyPI publication was disabled for this release,
102
+ therefore PyPI registry identity is not claimed. GitHub artifact attestations
103
+ were skipped by current repository policy, therefore artifact attestation is
104
+ not claimed.
105
+
106
+ ## Consumer Evidence
107
+
108
+ `CONSUMER-01` was admitted on 2026-07-03 from a private first consumer
109
+ repository checkout at `4cecdf8` using these consumer-owned gates:
110
+
111
+ ```bash
112
+ bun run verify:proofkit-external-consumer
113
+ bun scripts/report-proofkit-external-consumer.selftest.ts
114
+ bun scripts/lib/proofkit-runtime.selftest.ts
115
+ bun scripts/verify-workspace-script-registry.selftest.ts
116
+ bun run verify:proofkit-pilot
117
+ bun run verify:proofkit-requirement-source
118
+ bun run verify:proofkit-requirement-coverage
119
+ ```
120
+
121
+ The machine report for `bun scripts/report-proofkit-external-consumer.ts
122
+ --format json` emitted `reportKind: proofkit.registry-consumer`, `state:
123
+ passed`, `packageName: agentic-proofkit`, `packageVersion: 0.1.134`,
124
+ `registryUrl: https://registry.npmjs.org`, `tarballShasum:
125
+ 6029a30b232c87f9aff659b4d8d5dbb4536a0d25`, `frozenLockUsesWorkspace:
126
+ false`, `releaseAuthorityReportKind: proofkit.release-authority`,
127
+ `releaseAuthorityState: passed`, and `rollbackLockContainsPackage: false`.
128
+
129
+ This evidence does not claim npm publication from this public source
130
+ repository, Trusted Publisher configuration, public-source release provenance,
131
+ provider-side security ingestion, PyPI publication, second-consumer reuse,
132
+ native consumer test execution by Proofkit, rollout readiness, production
133
+ readiness, or retirement of consumer-owned product semantics.
134
+
135
+ `CONSUMER-02` was admitted on 2026-07-03 from a private topology-distinct
136
+ consumer module using explicit caller-owned warn-mode adoption facts. The
137
+ Proofkit guidance report emitted `reportKind:
138
+ proofkit.gradual-adoption-guidance`, `state: passed`, `guidanceMode: warn`,
139
+ `candidateBoundaryCount: 1`, `proofBindingMissingCount: 2`, and warning rules
140
+ for `proofkit.gradual-adoption-guidance.missing-proof-bindings` and
141
+ `proofkit.gradual-adoption-guidance.candidate-boundaries`. The companion agent
142
+ envelope emitted `route`, `bind`, `modernize-boundary`, `verify`, and
143
+ `promote` actions, with candidate-boundary context refs and explicit
144
+ instructions to keep native witness execution outside Proofkit.
145
+
146
+ Gap classification:
147
+
148
+ - Generic Proofkit work: no confirmed blocker. The current CLI accepted
149
+ explicit caller facts, preserved advisory candidate-boundary semantics, kept
150
+ missing binding records as warnings in warn mode, and emitted bounded agent
151
+ guidance without scanning repository state.
152
+ - Consumer-local adapter work: the consumer still needs owner-reviewed
153
+ `requirements.v1.json` records, requirement-to-proof bindings, native witness
154
+ command records, and a repository-local environment that can run its existing
155
+ coverage-map and backend test commands. Native witness attempts were blocked
156
+ by consumer-local dependency/bootstrap preconditions, not by Proofkit command
157
+ semantics.
158
+
159
+ This evidence does not claim second-consumer enforcement, native witness
160
+ success, consumer rollout, production readiness, public package publication
161
+ from this source repository, provider-side registry evidence, or retirement of
162
+ consumer-owned coverage-map and test authority.
163
+
164
+ ## Import Discipline
165
+
166
+ Old local repository content is not automatically authoritative. A transfer
167
+ batch is admissible only when:
168
+
169
+ ```text
170
+ candidate file set
171
+ and owner boundary
172
+ and stale/private fact scan
173
+ and lower-cost alternative review
174
+ and proof gate
175
+ and non-claims
176
+ ```
177
+
178
+ Code from the old local repository is rejected when it would delete current
179
+ hardening, weaken package verification, remove non-disclosure tests, reduce
180
+ semantic-route proof, or replace current public-source wording with private
181
+ repository facts.
182
+
183
+ ## Historical Import Discipline
184
+
185
+ Pre-cutover design documents and implementation plans are not retained in this
186
+ repository as current authority. Stable claims must move into deterministic
187
+ surfaces:
188
+
189
+ - `docs/specs/**/requirements.v1.json` for durable requirements;
190
+ - `proofkit/requirement-bindings.json` and `proofkit/witness-plan.json` for
191
+ proof routes;
192
+ - source code and tests for executable behavior;
193
+ - package-public docs only when consumers need stable operational guidance;
194
+ - this backlog only for open, falsifiable work.
195
+
196
+ Temporary design, implementation-plan, PR, code, or test observations may be
197
+ caller-owned inputs to authoring commands, but they must not become tracked
198
+ repository authority unless rewritten into one of the deterministic surfaces
199
+ above.
200
+
201
+ Architecture documents, ADRs, or roadmap documents are not banned by type. They
202
+ are admitted only when they are the lowest-cost current authority for a real
203
+ architecture decision, migration sequence, release obligation, or adoption
204
+ contract. An admitted architecture document must state its owner, scope, proof
205
+ path, non-claims, and retirement or supersession condition; otherwise the claim
206
+ belongs in `requirements.v1.json`, machine contracts, executable tests,
207
+ package-public operational docs, or this backlog.
208
+
209
+ ## Non-Goals
210
+
211
+ - Proofkit does not own product semantics for consuming repositories.
212
+ - Proofkit does not become a CI runner, repository scanner, policy owner, or
213
+ proof freshness authority.
214
+ - Proofkit does not require generated HTML, generated Markdown, or generated
215
+ lookup graphs to be committed by default.
216
+ - Proofkit does not require a rewrite in another language without measured
217
+ evidence that the current Go CLI is the limiting factor.
@@ -0,0 +1,70 @@
1
+ # Contributing
2
+
3
+ Thank you for improving `agentic-proofkit`.
4
+
5
+ This project accepts changes that preserve Proofkit's boundary as a reusable
6
+ CLI/JSON proof infrastructure toolkit. Consumer-specific policy, product
7
+ semantics, native witness execution, proof freshness decisions, merge
8
+ admission, and rollout approval belong in consuming repositories.
9
+
10
+ ## Start Here
11
+
12
+ 1. Read [AGENTS.md](AGENTS.md) for repository authority, proof, and closeout
13
+ rules.
14
+ 2. Use [README.md](README.md) for human orientation.
15
+ 3. Use [docs/proofkit-contract-map.md](docs/proofkit-contract-map.md) to find
16
+ the owner command or primitive.
17
+ 4. Use [ADOPTION.md](ADOPTION.md) for dependency and channel authority.
18
+ 5. Use [BACKLOG.md](BACKLOG.md) to check completion criteria and open work.
19
+ 6. Use [NON_CLAIMS.md](NON_CLAIMS.md) to understand the boundary between
20
+ Proofkit mechanics and consuming-repository authority.
21
+
22
+ ## Local Checks
23
+
24
+ Run before proposing a non-trivial change:
25
+
26
+ ```bash
27
+ npm run check
28
+ git diff --check
29
+ ```
30
+
31
+ For CLI or Go changes, run focused Go tests first. For package or release
32
+ changes, inspect [docs/release-process.md](docs/release-process.md).
33
+
34
+ ## Change Admission
35
+
36
+ An accepted change should have:
37
+
38
+ - one clear owner scope;
39
+ - a named invariant or contract it improves;
40
+ - the lower-cost alternative considered and rejected;
41
+ - proof that matches the changed evidence class;
42
+ - explicit non-claims when the change does not prove runtime, release,
43
+ consumer adoption, native witness execution, or rollout readiness.
44
+
45
+ Do not add generated HTML, generated lookup graphs, local artifacts, package
46
+ tarballs, `dist/`, `artifacts/`, `node_modules/`, credentials, or consumer
47
+ repository snapshots to source control unless a release owner explicitly
48
+ admits the artifact.
49
+
50
+ ## Pull Requests
51
+
52
+ Pull requests are maintainer-controlled. Public users may open issues, but pull
53
+ request creation is restricted to collaborators until the governance model
54
+ changes.
55
+
56
+ Use concise pull requests. The title and summary should state the exact owner
57
+ scope and reviewable outcome. Avoid copied logs, stale checklists, and broad
58
+ "cleanup" claims.
59
+
60
+ Good PR descriptions answer:
61
+
62
+ - what changed;
63
+ - why the owner boundary is correct;
64
+ - what proof ran;
65
+ - what is not claimed.
66
+
67
+ ## Conduct
68
+
69
+ Be direct, evidence-based, and respectful. Disagreement should focus on the
70
+ invariant, owner boundary, proof, and lower-cost alternative.
package/LICENSE ADDED
@@ -0,0 +1,21 @@
1
+ MIT License
2
+
3
+ Copyright (c) 2026 Research Engineering contributors
4
+
5
+ Permission is hereby granted, free of charge, to any person obtaining a copy
6
+ of this software and associated documentation files (the "Software"), to deal
7
+ in the Software without restriction, including without limitation the rights
8
+ to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
9
+ copies of the Software, and to permit persons to whom the Software is
10
+ furnished to do so, subject to the following conditions:
11
+
12
+ The above copyright notice and this permission notice shall be included in all
13
+ copies or substantial portions of the Software.
14
+
15
+ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
16
+ IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
17
+ FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
18
+ AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
19
+ LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
20
+ OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
21
+ SOFTWARE.