bootproof 0.1.0 → 0.4.0

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/RELEASE_CHECKLIST.md

@@ -71,4 +71,12 @@ BootProof publishes compiled JavaScript, not TypeScript source. `dist/` is requi
    npx bootproof up https://github.com/user/repository
    ```
 
-Remote URL mode accepts credential-free public HTTPS GitHub repositories. It retains clones under `.bootproof/remotes/` and requires `--provider local --unsafe-local` before executing remote repository code.
+Remote URL mode accepts credential-free public HTTPS repositories from GitHub, GitLab, Bitbucket, and Codeberg. It retains clones under `.bootproof/remotes/` and requires `--provider local --unsafe-local` before executing remote repository code.
+
+Remote repair follows the same rule:
+
+```bash
+npx bootproof fix https://github.com/user/repository --provider local --unsafe-local
+```
+
+`fix` never mutates the source tree. `apply-repair` is the separate explicit application step and refuses invalid signatures, disallowed paths, and stale preimages.

package/docs/REPAIR_RECEIPT.md

@@ -0,0 +1,224 @@
+# Repair Receipts
+
+`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.
+
+Receipts preserve the complete lifecycle:
+
+- suggested
+- approved or declined
+- applied or failed
+- progressed or unchanged
+- verified or unverified
+
+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
+
+```text
+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",
+  "tool": "bootproof@0.3.0",
+  "repo": {
+    "remote": null,
+    "commit": null,
+    "dirty": null
+  },
+  "environment": {
+    "os": "darwin 25.4.0",
+    "arch": "arm64",
+    "node": "v22.0.0"
+  },
+  "failure": {
+    "class": "service_port_allocated",
+    "beforeAttestationSha256": "..."
+  },
+  "repair": {
+    "id": "remap-conflicting-service-port",
+    "kind": "plan-step",
+    "description": "...",
+    "diff": null,
+    "filesChanged": [
+      "docker-compose.bootproof.override.yml"
+    ],
+    "fileChanges": [
+      {
+        "path": "docker-compose.bootproof.override.yml",
+        "beforeSha256": null,
+        "afterSha256": "...",
+        "beforeContent": null,
+        "afterContent": "..."
+      }
+    ],
+    "preconditions": [
+      {
+        "path": "docker-compose.yml",
+        "sha256": "..."
+      }
+    ],
+    "planDelta": "...",
+    "envDelta": null
+  },
+  "verification": {
+    "before": {
+      "booted": false,
+      "failureClass": "service_port_allocated",
+      "attestationSha256": "..."
+    },
+    "after": {
+      "booted": true,
+      "healthObservation": "HTTP 200 at http://localhost:4000/",
+      "attestationSha256": "..."
+    }
+  },
+  "startedAt": "...",
+  "finishedAt": "...",
+  "signer": {
+    "publicKey": "...",
+    "algorithm": "ed25519"
+  },
+  "signature": "..."
+}
+```
+
+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.
+
+## Result Interface
+
+```bash
+bootproof fix . --json
+```
+
+emits exactly one:
+
+```text
+bootproof/repair-result/v1
+```
+
+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.
+
+Local sandbox execution still requires:
+
+```bash
+bootproof fix . --provider local --unsafe-local
+```
+
+Remote repair accepts credential-free public HTTPS repositories from GitHub, GitLab, Bitbucket, and Codeberg and keeps all evidence in the retained clone:
+
+```bash
+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:
+
+```bash
+bootproof apply-repair .
+```
+
+Application exits `0` only after all signed file changes are written and re-hashed. It writes nothing when:
+
+- the receipt signature is invalid
+- a path is outside the repair allowlist
+- signed content hashes are inconsistent
+- a signed read-only repair prerequisite changed
+- the current file preimage differs from the verified preimage
+- the receipt is environment-only or plan-only
+
+`bootproof apply-repair . --dry-run` writes nothing. No repair is ever auto-applied by `bootproof fix`.
+
+## v0.3 Registry
+
+| 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. |
+
+There are no LLM calls in the repair registry.
+
+Local host execution still requires `--unsafe-local`, and `fix` never auto-applies a repair. These are honesty boundaries. The separate application command exists so mutation is deliberate and independently verified.
+
+## Files
+
+Repair output is kept in the original repository's BootProof output directory:
+
+```text
+.bootproof/attestation.json
+.bootproof/repair-receipt.json
+.bootproof/repair-after-attestation.json
+.bootproof/repair-<id>.patch
+```
+
+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 exists only when an approved command triggered a rerun. It is retained so
+progress and verification can be inspected independently.
+
+## Allowed Scope
+
+Repair file changes are hard-limited to:
+
+- `package.json`, and only its `engines` or `packageManager` keys
+- lockfiles
+- `*.bootproof.*` files
+- `.env*.example` files
+- Compose override files created by BootProof
+
+Application source is outside repair scope. A remediation that attempts to edit it throws an honesty-contract violation.
+
+Repository Compose repair files are complete copies invoked directly. They do not rely on the version-specific `!override` merge tag, and they are written beside the source Compose file so relative build contexts keep the same base directory.

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"
+  ]
+}
+