bootproof 0.3.0 → 0.4.1

package/docs/REGISTRY.md

@@ -1,49 +1,69 @@
-# Git-Native Registry Design
+# Registry Export Formats
 
-BootProof does not operate a public registry service today.
+BootProof supports local, redacted registry artifacts. It does not operate a public index from
+this repository, upload evidence automatically, or call a registry service.
 
-The current primitive is portable signed evidence:
+Create a local entry explicitly:
 
-```text
-.bootproof/attestation.json
+```bash
+bootproof registry export .
 ```
 
-Projects may deliberately commit that file or export a redacted entry:
+This writes `.bootproof/registry-entry.json` using
+`bootproof/registry-entry/v1`. `bootproof attest export .` remains a compatibility alias.
 
-```bash
-bootproof attest export .
-```
+## Public/Federated Registry
 
-This writes:
+Public repositories may explicitly create a public-candidate wrapper:
 
-```text
-.bootproof/registry-entry.json
+```bash
+bootproof registry export . --federated
 ```
 
-Nothing is uploaded automatically.
+This writes a redacted, signed `bootproof/federated-receipt/v1` artifact under
+`.bootproof/registry/`. A repository owner may review and deliberately commit that receipt to
+the repository's own Git history.
+
+A future BootProof indexer could crawl public receipts, verify signatures, and build an open
+commons of verified boot, failure, and repair knowledge. The crawler and public index do not
+exist in this repository and are not implemented by this command.
 
-## Intended Design
+`bootproof attest check` distinguishes this machine's signer, explicitly pinned known signers,
+and unknown foreign signers. Signature integrity alone does not establish authorship.
 
-The proposed registry model is federated:
+## Private Cloud Registry
 
-- write path: repositories deliberately publish signed proof through Git
-- read path: a future index discovers public attestations, verifies signatures, and links claims to source commits
-- failure corpus: classified failures improve detectors without converting failures into success claims
+Organisations may later explicitly upload redacted attestations and repair receipts to
+BootProof Cloud. Private repository data would remain governed, tenant-isolated, and paid.
 
-The index, badge service, freshness tracking, and signer trust graph are roadmap items. They are not deployed capabilities.
+This repository only supports producing a `cloud_upload_candidate` local export. BootProof
+Cloud, upload transport, billing, governance, and hosted registry storage are intentionally
+not implemented here.
 
 ## Consent And Privacy
 
-1. BootProof sends no telemetry or hidden evidence upload.
-2. Sharing requires a visible local artifact and an explicit user action.
-3. Full local attestations may contain raw failure evidence.
-4. Registry export applies redaction and records which redactions were used.
-5. A future index should trust only valid signatures and public evidence.
+1. Every registry entry has `optInRequired: true`; federated wrappers contain that entry.
+2. Export builders perform no network calls and do not upload telemetry or evidence.
+3. Files are written only after an explicit export command.
+4. Raw environment values, tokens, private keys, protected `.env` contents, and local username
+   paths are excluded or redacted.
+5. Repository owner and name identifiers are hashed; a public repository URL is included only
+   when it is a credential-free URL on a supported public Git host.
+6. Full local attestations may contain raw evidence and should not be treated as public exports.
+
+The strict schemas are:
 
-Repository commands executed by BootProof may access the network independently. The no-upload promise applies to BootProof's own telemetry and evidence handling, not arbitrary install or application commands.
+- [`schemas/registry-entry-v1.schema.json`](schemas/registry-entry-v1.schema.json)
+- [`schemas/federated-receipt-v1.schema.json`](schemas/federated-receipt-v1.schema.json)
 
-## Trust
+## Documentation Seeds
 
-Current attestations are `local_developer_signed`.
+Small synthetic examples of the real-world classifier and inference coverage live
+under [`examples/registry-seeds/`](examples/registry-seeds/). They use the
+documentation-only
+[`registry-seed-example-v1` schema](schemas/registry-seed-example-v1.schema.json)
+and are explained in [REAL_WORLD_FIXTURES.md](REAL_WORLD_FIXTURES.md).
 
-CI/OIDC-backed proof will be stronger because a verifier can bind the signature to a repository workflow identity. BootProof does not claim that trust level yet.
+These examples are not attestations, proof, upload requests, or production
+registry entries. They contain no network behavior and are never submitted
+automatically.

package/docs/REPAIR_RECEIPT.md

@@ -1,13 +1,20 @@
 # Repair Receipts
 
-`bootproof fix` treats the normal BootProof verdict as an oracle. A signature-valid failed attestation is reused only when it identifies the exact current clean Git commit. Otherwise BootProof reproduces the failed run in a temporary copy. It applies one deterministic registered remediation there and reruns full verification.
+`bootproof fix` treats the normal BootProof verdict as the oracle. The deterministic MVP reads
+the latest signature-valid classified failure and maps only exact known evidence to a repair
+action. It never uses AI.
 
-No receipt is emitted unless both statements are signed evidence:
+Receipts preserve the complete lifecycle:
 
-- before: the sandbox run failed with a classified failure
-- after: the remediated sandbox run observed successful HTTP health
+- suggested
+- approved or declined
+- applied or failed
+- progressed or unchanged
+- verified or unverified
 
-`bootproof fix` does not edit the original repository. A human may review the patch written under `.bootproof/` and explicitly invoke `bootproof apply-repair`.
+Declined and failed attempts are valuable evidence, so they also produce signed receipts.
+Only observed healthy HTTP sets `verified: true`. Progress without verification requires a
+different after failure class.
 
 ## Schema
 
@@ -15,6 +22,16 @@ No receipt is emitted unless both statements are signed evidence:
 bootproof/repair-receipt/v1
 ```
 
+The strict machine schemas are:
+
+- [`schemas/repair-action-v1.schema.json`](schemas/repair-action-v1.schema.json)
+- [`schemas/repair-receipt-v1.schema.json`](schemas/repair-receipt-v1.schema.json)
+
+The v1 receipt now includes additive safety-foundation fields: the deterministic proposed
+action, mutation scope, risk level, approval requirement, apply result, progress and
+verification booleans, and redaction record. Existing signed verification fields remain for
+backward-compatible inspection and application.
+
 ```json
 {
   "schema": "bootproof/repair-receipt/v1",
@@ -83,6 +100,10 @@ bootproof/repair-receipt/v1
 
 The receipt uses the same Ed25519 canonical-body pattern as attestations: `signer` and `signature` are excluded from the signed body. Tampering with the repair, before result, or after result invalidates verification.
 
+An intact signature establishes integrity, not authorship by itself. `bootproof verify` reports
+whether the repair receipt signer is this machine, explicitly known, or unknown foreign, using
+the same local trust store as attestation verification.
+
 `beforeAttestationSha256` and both verification hashes are SHA-256 hashes of the corresponding attestation JSON objects.
 
 `fileChanges` is a signed application manifest. It contains only allowlisted boot-plumbing files and binds the expected preimage and verified after-content to SHA-256 hashes. `preconditions` binds read-only source inputs, such as the repository Compose file from which a repaired copy was derived.
@@ -99,7 +120,8 @@ emits exactly one:
 bootproof/repair-result/v1
 ```
 
-Exit `0` means a signed repair receipt was produced after observed HTTP health. Every unknown, inapplicable, failed, or unverified remediation exits `1`.
+Exit `0` means the rerun observed healthy HTTP. A declined, failed, progressed-but-unverified,
+unknown, or inapplicable remediation exits `1`, even when a signed receipt was written.
 
 `bootproof fix . --dry-run` executes nothing, writes nothing, and produces no proof.
 
@@ -117,6 +139,17 @@ bootproof fix https://github.com/user/repo --provider local --unsafe-local
 
 Cloning is not execution consent. The existing local execution acknowledgement remains mandatory.
 
+Human command repairs show:
+
+```text
+This repair may modify your local machine or services.
+Command: <exact command>
+Risk: medium
+Run this command? Type Y to approve:
+```
+
+Only uppercase `Y` approves. JSON and CI modes never prompt and never execute a repair command.
+
 ## Explicit Application
 
 Repair generation and repair application are separate operations:
@@ -140,6 +173,18 @@ Application exits `0` only after all signed file changes are written and re-hash
 
 | Failure class | Deterministic remediation |
 |---|---|
+| `missing_ruby_version` | Propose `rbenv install <requiredVersion>` as a medium-risk host mutation. |
+| `missing_build_tool` with exact CMake evidence | Propose `brew install cmake` as a host mutation requiring approval. |
+| `native_extension_compile_failed` for `idn-ruby` | Propose Homebrew native dependencies, then a separately approved static-prefix Bundler configuration action. |
+| `missing_database_config` | Preview a patch copying the repository PostgreSQL/example config when the destination is absent and the content is safe to persist. |
+| `missing_required_config` for `config/gitlab.yml` | Preview a patch copying `config/gitlab.yml.example` when the destination is absent. |
+| `postgres_unavailable` | Start only a detected local Homebrew PostgreSQL package and show `pg_isready`; otherwise emit an instruction. |
+| `postgres_role_missing` | Propose `createuser -s <role>` only for an exact shell-safe role from evidence. |
+| `database_schema_missing` | Propose high-risk `bundle exec rails db:migrate`. |
+| `unsupported_database_version` | Propose separate high-risk install and service-start actions for the exact PostgreSQL major without changing PATH. |
+| `unsupported_database_config` | Preview removal of only exact `geo`/`embedding` top-level sections when the patch contains no secrets. |
+| `redis_unavailable` | Propose `brew services start redis` when Homebrew is detectable; otherwise emit a generic instruction. |
+| `missing_env_var` for only `RAILS_ENV` | Emit `RAILS_ENV=development bootproof up . --provider local --unsafe-local --install` as a non-executed instruction. |
 | `service_port_allocated` | Remap a BootProof-generated Compose host port, or create a complete BootProof-owned repaired Compose copy beside the repository file without editing it. |
 | `package_manager_version_mismatch` | Run the exact declared `corepack prepare <manager>@<version> --activate` command in the sandbox. |
 | `migrations_missing` | Select one exact migration framework from repository markers plus preserved evidence: Prisma, Django, Rails, Knex, or Drizzle. Ambiguous matches refuse instead of guessing. |
@@ -150,7 +195,7 @@ Local host execution still requires `--unsafe-local`, and `fix` never auto-appli
 
 ## Files
 
-Successful repair output is kept in the original repository's BootProof output directory:
+Repair output is kept in the original repository's BootProof output directory:
 
 ```text
 .bootproof/attestation.json
@@ -161,7 +206,8 @@ Successful repair output is kept in the original repository's BootProof output d
 
 The patch is present only when the repair produced a repository or repaired-Compose file change. Plan-only and environment-only repairs may have no patch.
 
-The after attestation is retained so its signature and receipt hash can be inspected independently. Sandbox paths in that attestation describe where verification actually occurred.
+The after attestation exists only when an approved command triggered a rerun. It is retained so
+progress and verification can be inspected independently.
 
 ## Allowed Scope
 

package/docs/agent-loop-gap-analysis.md

@@ -0,0 +1,188 @@
+# Agent-Loop Gap Analysis
+
+Audit date: 2026-06-12
+
+Target architecture:
+
+> Diagnose -> Classify -> Plan -> Risk-Classify -> Approve -> Execute One Step
+> -> Verify -> Receipt -> Repeat
+
+This document tracks the current OSS agent-loop architecture. It does not
+authorize autonomous execution.
+
+## Status Summary
+
+| Capability | Status | Current repository state |
+|---|---|---|
+| Engineering constitution | Exists | `AGENTS.md` contains the complete agent-loop principles, approval boundary, one-step rule, verification rule, receipt rule, honest-stop rule, and OSS/Cloud boundary. |
+| External health verification | Exists | `verify-url` and `up --external-health` record external-health attestations with explicit non-orchestration ownership and honest auth/unreachable classifications. |
+| Agent planning | Planning-only foundation exists | `bootproof plan-agent` writes a strict local agent plan with evidence, risk-classified candidate actions, approvals, verification steps, and stop conditions. It executes no candidate action. |
+| Shared action risk model | Exists | Deterministic repair and `plan-agent` use one strict action-risk classifier with canonical mutation scopes, approval prompts, blocked reasons, verification steps, a hard blocklist, and at-least-medium risk for unknown commands. |
+| Airbyte runbook recognition | Exists | Planning identifies Airbyte from repository identity and structural evidence, emits the abctl-managed orchestration classifications, uses the shared high-risk Kubernetes model, marks credential access secret-sensitive, and plans external health verification without execution. |
+| Local agent receipt chain | Exists for planning and verification | `plan-agent` creates a redacted run directory with hash-linked diagnosis, plan, and action receipts. Repository-scoped external health can append verification receipts, the derived final summary states ownership and stop status, and `explain-run` verifies the chain. Approved action execution remains intentionally unimplemented. |
+
+## Existing Capabilities
+
+### Constitution
+
+`AGENTS.md` already states that BootProof may plan and risk-classify actions,
+may execute only approved local actions, must execute one step at a time,
+must verify after every action, must save local receipts, and must stop on
+unknown or unsafe steps.
+
+It also preserves these boundaries:
+
+- `bootproof up` is deterministic, zero-AI, and evidence-based.
+- Planning and action completion are not proof.
+- External health must not imply that BootProof started the application.
+- AI assistance is optional and must use the same safety model.
+- Cloud/SaaS, telemetry, and automatic upload remain outside this OSS repo.
+
+### Deterministic Repair Loop
+
+The current `bootproof fix` path implements a human-driven subset of the loop:
+
+- reads a signature-valid failed attestation;
+- classifies exact known evidence;
+- selects one deterministic repair candidate;
+- displays action type, mutation scope, risk, and exact command or patch;
+- requires uppercase `Y` for command or patch testing;
+- executes only the selected action;
+- reruns BootProof in a sandbox;
+- records declined, failed, progressed, or verified outcomes;
+- writes a signed local repair receipt.
+
+Later candidate actions may be displayed, but they are not silently chained or
+executed in the same approval.
+
+### Health and Evidence Primitives
+
+The health engine already:
+
+- records requested URL, HTTP status, headers, redirect location, body excerpt,
+  timestamp, acceptance decision, and connection errors;
+- accepts HTTP 2xx and expected application sign-in redirects;
+- preserves failed observations;
+- clears stale health evidence during later successful observations.
+
+External verification now provides `bootproof verify-url <url>` and
+`bootproof up . --external-health <url>`. Its attestations use
+`verificationMode: external-health`, set `bootproofOrchestrated: false`, and
+classify successful HTTP 2xx/3xx observations as `external_service_verified`.
+HTTP 401/403 is `auth_required`; connection and non-success responses are
+`external_health_unreachable`.
+
+### Safety and Receipt Primitives
+
+`bootproof/repair-action/v1` currently provides:
+
+- `actionType`;
+- `mutationScope`;
+- `riskLevel`;
+- `requiresApproval`;
+- structured commands, patches, and instructions;
+- a hard safety validator for shell control, `sudo`, destructive commands,
+  protected environment files, blocked paths, and exfiltration patterns.
+
+`bootproof/repair-receipt/v1` currently records:
+
+- proposed action and risk fields;
+- approval and application timestamps;
+- apply result;
+- before and after failure classes;
+- progress and verification;
+- redactions;
+- signature-valid before/after attestation hashes when available.
+
+## Partial Capabilities
+
+### Run Planning
+
+`bootproof plan` is planning-only and performs no execution or writes. Its
+`RunPlan` steps contain an identifier, kind, optional command, description,
+and required flag.
+
+It is not an agent plan because it does not contain:
+
+- candidate alternatives;
+- per-action risk classification;
+- mutation scope;
+- approval requirement;
+- blocked reason;
+- verification step;
+- secret-sensitivity metadata;
+- a persisted `.bootproof/agent-plan.json`.
+
+### Shared Risk Model
+
+The deterministic repair safety module is the shared action-risk contract used
+by deterministic repair and `plan-agent`. It provides:
+
+- canonical action type, mutation scope, risk, and approval fields;
+- generated approval prompts, blocked reasons, and verification steps;
+- deterministic high-risk classification for host installs, Kubernetes
+  mutations, database migrations, and credential generation;
+- at-least-medium classification for unknown commands;
+- one hard blocklist before any command can become executable.
+
+Deterministic repair actions remain sourced from `deterministic_playbook`.
+`plan-agent` consumes the same classifier but remains planning-only.
+
+### Receipt History
+
+BootProof writes `.bootproof/attestation.json`,
+`.bootproof/repair-receipt.json`, and, after a rerun,
+`.bootproof/repair-after-attestation.json`. Repair receipts are signed and bind
+before/after attestations with hashes.
+
+Repair files remain attempt-scoped. Agent planning now additionally creates a
+run-scoped local chain under `.bootproof/agent-runs/<run-id>/`, where immutable
+diagnosis, plan, action, and verification receipts link by SHA-256 hash.
+`final-summary.json` records the current derived status, and
+`bootproof explain-run <run-id>` verifies and explains the chain.
+
+## Existing Agent Run Capability
+
+- `.bootproof/agent-runs/<run-id>/`;
+- redacted initial attestation and plan snapshots;
+- per-action planning receipts;
+- appendable verification receipts;
+- previous-receipt SHA-256 links;
+- a derived final summary;
+- `bootproof explain-run <run-id>`.
+
+Planning still executes nothing. No autonomous or approved action runner exists.
+
+## Recommended Next Prompt Order
+
+1. **Only after the receipt contracts are stable, add a human-driven
+   single-step runner.**
+   Execute exactly one approved local action, verify it, write the chained
+   receipts, and stop for a new explicit approval. Do not add autonomous
+   multi-step execution in this stage.
+
+## Files Inspected
+
+- `AGENTS.md`
+- `src/cli.ts`
+- `src/types.ts`
+- `src/infer.ts`
+- `src/plan.ts`
+- `src/run.ts`
+- `src/exec.ts`
+- `src/proof.ts`
+- `src/taxonomy.ts`
+- `src/diagnosis.ts`
+- `src/repair-safety.ts`
+- `src/repair-playbooks.ts`
+- `src/repair.ts`
+- `src/registry.ts`
+- `docs/DETERMINISTIC_REPAIR_SAFETY_MODEL.md`
+- `docs/FAILURE_TAXONOMY.md`
+- `docs/HONESTY_CONTRACT.md`
+- `docs/REPAIR_RECEIPT.md`
+- `docs/REGISTRY.md`
+- `docs/schemas/repair-action-v1.schema.json`
+- `docs/schemas/repair-receipt-v1.schema.json`
+- `tests/unit.test.mjs`
+- `tests/e2e.test.mjs`

package/docs/examples/registry-seeds/advertised-port-mismatch.json

@@ -0,0 +1,28 @@
+{
+  "schema": "bootproof/registry-seed-example/v1",
+  "name": "advertised-port-mismatch",
+  "source": "synthetic_minimal_fixture",
+  "structuralMarkers": [
+    "selected command starts a Vite asset server",
+    "inferred health URL uses port 8080",
+    "process output advertises https://localhost:5173/",
+    "no successful response on inferred health candidate"
+  ],
+  "expectedBootProof": {
+    "kind": "classification",
+    "values": [
+      "health_candidate_port_mismatch"
+    ]
+  },
+  "safeNextStep": "Confirm whether the advertised endpoint is an asset server or the primary application, correct the reviewed health target, and rerun verification.",
+  "repairDisposition": "refused",
+  "externallyOrchestrated": false,
+  "evidenceOutcome": "diagnostic_only",
+  "verificationBasis": "An advertised URL mismatch is precise failure evidence, not successful health evidence; BootProof must still observe the intended application endpoint.",
+  "redactionsApplied": [
+    "only localhost URL patterns included",
+    "no response body data included",
+    "no local username paths included"
+  ]
+}
+

package/docs/examples/registry-seeds/airbyte-abctl-external-orchestrator.json

@@ -0,0 +1,36 @@
+{
+  "schema": "bootproof/registry-seed-example/v1",
+  "name": "airbyte-abctl-external-orchestrator",
+  "source": "synthetic_minimal_fixture",
+  "structuralMarkers": [
+    "Airbyte Open Source README marker",
+    "settings.gradle root project airbyte",
+    "airbyte-cdk/",
+    "airbyte-integrations/",
+    "docker-images/",
+    "docs mention abctl",
+    "kind and Helm deployment markers"
+  ],
+  "expectedBootProof": {
+    "kind": "agent_plan",
+    "values": [
+      "airbyte_abctl_managed",
+      "large_orchestration_repo",
+      "external_orchestrator_required",
+      "kind_kubernetes_backed",
+      "helm_deployed",
+      "auth_required"
+    ]
+  },
+  "safeNextStep": "Review host tooling, explicitly approve the high-risk abctl local install step outside bootproof up, then use bootproof verify-url against http://localhost:8001/api/v1/health.",
+  "repairDisposition": "approval_required",
+  "externallyOrchestrated": true,
+  "evidenceOutcome": "verified_boot_possible",
+  "verificationBasis": "An observed successful external health response can verify the already-running service, but BootProof must not claim that it started Airbyte.",
+  "redactionsApplied": [
+    "no credentials output included",
+    "no Kubernetes secrets included",
+    "no copied vendor manifests included"
+  ]
+}
+

package/docs/examples/registry-seeds/go-ollama-service.json

@@ -0,0 +1,36 @@
+{
+  "schema": "bootproof/registry-seed-example/v1",
+  "name": "go-ollama-service",
+  "source": "synthetic_minimal_fixture",
+  "structuralMarkers": [
+    "go.mod",
+    "main.go",
+    "cmd/",
+    "OLLAMA_HOST",
+    "serve command",
+    "port 11434",
+    "/api/tags"
+  ],
+  "expectedBootProof": {
+    "kind": "classification_and_inference",
+    "values": [
+      "go-backend",
+      "go run . serve",
+      "go_runtime_missing",
+      "go_build_failed",
+      "http://127.0.0.1:11434/",
+      "http://127.0.0.1:11434/api/tags"
+    ]
+  },
+  "safeNextStep": "Use the evidenced Go serve command only when the repository markers support it, then require an observed HTTP response on port 11434.",
+  "repairDisposition": "refused",
+  "externallyOrchestrated": false,
+  "evidenceOutcome": "verified_boot_possible",
+  "verificationBasis": "Observed HTTP 200 health from the root or /api/tags can verify the service; Go markers and a running process cannot.",
+  "redactionsApplied": [
+    "no model data included",
+    "no host environment values included",
+    "no local username paths included"
+  ]
+}
+

package/docs/examples/registry-seeds/laravel-vite-sqlite.json

@@ -0,0 +1,36 @@
+{
+  "schema": "bootproof/registry-seed-example/v1",
+  "name": "laravel-vite-sqlite",
+  "source": "synthetic_minimal_fixture",
+  "structuralMarkers": [
+    "artisan",
+    "composer.json",
+    "package.json",
+    "vite.config.js",
+    ".env.example",
+    "Connection: sqlite",
+    "database/database.sqlite missing"
+  ],
+  "expectedBootProof": {
+    "kind": "classification_and_inference",
+    "values": [
+      "php-backend",
+      "laravel",
+      "node-frontend",
+      "vite",
+      "laravel_sqlite_database_missing",
+      "laravel_migrations_required"
+    ]
+  },
+  "safeNextStep": "Review creation of database/database.sqlite, separately approve php artisan migrate, then rerun the Laravel application and require observed HTTP health.",
+  "repairDisposition": "approval_required",
+  "externallyOrchestrated": false,
+  "evidenceOutcome": "verified_boot_possible",
+  "verificationBasis": "A later observed HTTP 2xx response or accepted redirect to /login can verify the Laravel application; file creation and migration completion alone cannot.",
+  "redactionsApplied": [
+    "no environment values included",
+    "no database contents included",
+    "no local username paths included"
+  ]
+}
+

package/docs/examples/registry-seeds/monorepo-ambiguous-health.json

@@ -0,0 +1,29 @@
+{
+  "schema": "bootproof/registry-seed-example/v1",
+  "name": "monorepo-ambiguous-health",
+  "source": "synthetic_minimal_fixture",
+  "structuralMarkers": [
+    "root package.json workspaces",
+    "parallel root dev command",
+    "apps/web/package.json",
+    "apps/docs/package.json",
+    "multiple plausible health ports"
+  ],
+  "expectedBootProof": {
+    "kind": "classification",
+    "values": [
+      "workspace_ambiguous"
+    ]
+  },
+  "safeNextStep": "Select one reviewed workspace explicitly and rerun BootProof against that application instead of guessing among parallel services.",
+  "repairDisposition": "refused",
+  "externallyOrchestrated": false,
+  "evidenceOutcome": "diagnostic_only",
+  "verificationBasis": "Ambiguous workspace markers justify refusal only; no workspace can be marked verified until its own health response is observed.",
+  "redactionsApplied": [
+    "workspace names are generic",
+    "no repository source included",
+    "no environment values included"
+  ]
+}
+

package/docs/examples/registry-seeds/php-composer.json

@@ -0,0 +1,33 @@
+{
+  "schema": "bootproof/registry-seed-example/v1",
+  "name": "php-composer",
+  "source": "synthetic_minimal_fixture",
+  "structuralMarkers": [
+    "composer.json",
+    "composer.lock",
+    "php command not found",
+    "composer command not found",
+    "lock file package PHP constraint mismatch",
+    "vendor/autoload.php missing"
+  ],
+  "expectedBootProof": {
+    "kind": "classification",
+    "values": [
+      "missing_php_runtime",
+      "missing_composer",
+      "unsupported_php_version_for_composer_lock",
+      "missing_php_vendor_autoload"
+    ]
+  },
+  "safeNextStep": "Select a PHP version compatible with composer.lock, install Composer through the documented local method, and run composer install without editing the lockfile as the first step.",
+  "repairDisposition": "refused",
+  "externallyOrchestrated": false,
+  "evidenceOutcome": "diagnostic_only",
+  "verificationBasis": "Runtime and dependency evidence can support only a failed diagnostic receipt until a separate application health check succeeds.",
+  "redactionsApplied": [
+    "no package registry credentials included",
+    "no private package names included",
+    "no local filesystem paths included"
+  ]
+}
+

package/docs/examples/registry-seeds/rails-bundler.json

@@ -0,0 +1,32 @@
+{
+  "schema": "bootproof/registry-seed-example/v1",
+  "name": "rails-bundler",
+  "source": "synthetic_minimal_fixture",
+  "structuralMarkers": [
+    "Gemfile",
+    "bin/rails",
+    "config/database.yml example marker",
+    "rbenv version is not installed",
+    "Gem::Ext::BuildError",
+    "Failed to build gem native extension"
+  ],
+  "expectedBootProof": {
+    "kind": "classification_and_inference",
+    "values": [
+      "ruby-backend",
+      "missing_ruby_version",
+      "native_extension_compile_failed"
+    ]
+  },
+  "safeNextStep": "Approve installation of the exact repository-required Ruby version or evidenced native build dependency, rerun dependency installation, then require observed Rails HTTP health.",
+  "repairDisposition": "approval_required",
+  "externallyOrchestrated": false,
+  "evidenceOutcome": "verified_boot_possible",
+  "verificationBasis": "An observed Rails HTTP response, including an accepted authentication redirect, may verify boot; successful Bundler installation is not proof.",
+  "redactionsApplied": [
+    "no Bundler credentials included",
+    "no database values included",
+    "no copied application configuration included"
+  ]
+}
+