CREEP

Current product position:

1. evidence package receipt
2. event-driven processing
3. traceability and attribution
4. source-specific adapters on top of a common ERP core

CREEP is no longer described here as an all-at-once digital factory.

The current wedge product is a practical ERP kernel that can:

1. receive upstream evidence packages
2. normalize stable identifiers and observations
3. emit internal workflow events
4. support failure-path tracing and attribution

Current Focus

The near-term implementation focus is:

1. baseline-like package intake
2. bronze, silver, and traceability layers
3. AssetEvent as the audit backbone
4. Wasm as a tagger, scorer, or rules step

Repository Layout

1. src/api/ for API endpoints
2. src/engine/ for event bus, worker logic, and wasm execution
3. src/oracles/ for source-specific ingest adapters
4. deploy/sql/ for schema and migrations
5. schemas/ for canonical contracts
6. docs/ for architecture, guides, and historical direction notes

Key Documents

1. docs/architecture/evidence-traceability-core.md
2. docs/architecture/hardware-fingerprint-grade-policy-v1.md
3. docs/guides/vcompose-light-containers.md
4. docs/guides/evidence-kernel-resident-ops.md
5. docs/guides/getting-started.md
6. docs/guides/evidence-trace-intake.md
7. docs/gaol.md for the earlier long-horizon vision
8. docs/research/hardware-fingerprint-internal-use-interview.md
9. docs/research/ip-internal-use-interview.md
10. docs/research/creep-internal-consumer-intro-email.md
11. docs/research/creep-fingerprint-export-schema-v0.1.json
12. docs/research/creep-asset-feedback-schema-v0.1.json
13. docs/research/ascension-first-wave-bridge-coordination-email.md
14. docs/research/ascension-first-wave-bridge-v0.1-freeze.md
15. docs/architecture/erp-evaluation-harness-v0.1.md
16. docs/architecture/feedback-taxonomy-v0.1.md
17. docs/reports/burnbag-baseline-20260424.md
18. docs/guides/cap010-live-evidence-bridge.md
19. docs/guides/cap010-live-dry-run-checklist.md
20. docs/research/cap010-live-bridge-ready-email.md
21. docs/architecture/payment-asset-sandbox-v0.1.md
22. docs/runbooks/cap010-creep-e2e-v0.1.md
23. docs/reports/cap010-creep-live-small-sample-20260604.md
24. docs/architecture/stripe-issuing-capability-evidence-v0.1.md
25. docs/architecture/tiny-live-authorization-plan-v0.1.md
26. docs/architecture/stripe-realtime-authorization-decision-v0.1.md
27. docs/architecture/stripe-webhook-boundary-harness-v0.1.md
28. docs/architecture/stripe-live-handler-readiness-v0.1.md
29. docs/architecture/vcc-real-money-gate-closeout-v0.1.md
30. docs/architecture/vcc-live-execution-gate-v0.1.md
31. docs/architecture/vcc-operator-arming-gate-v0.1.md
32. docs/architecture/vcc-master-key-operator-closeout-v0.1.md
33. docs/architecture/super-ledger-store-ingestion-v0.1.md

Runtime Entry Points

API

python -m uvicorn src.api.app:app --host 0.0.0.0 --port 8000

Baseline Intake

python -m src.evidence.baseline_ingest --input-dir <path> --tenant <tenant> --env <env>

Normalize Worker

python -m src.evidence.normalize_worker --once

Trace Worker

python -m src.evidence.trace_worker --once

Hardware Fingerprint Lineage Smoke

python -m src.evidence.lineage_smoke --tenant <tenant> --env <env>

Ascension Fingerprint Export

python -m src.assets.hardware_fingerprint.ascension_export \
  --tenant <tenant> \
  --env <env> \
  --project <project> \
  --task <task_id> \
  --grade-min 1A \
  --count 10 \
  --output out/ascension/creep-fingerprint-export.json

Asset Feedback Ingest

python -m src.assets.feedback_ingest \
  --input ascension-feedback.json

Asset Feedback Review

curl -H "X-API-Key: $ERP_API_KEY" \
  "$CREEP_API/api/v1/asset-feedback/events?recommended_asset_action=quarantine"

curl -H "X-API-Key: $ERP_API_KEY" \
  "$CREEP_API/api/v1/asset-feedback/disposition-summary?consumer_system=ascension"

Asset Feedback Review Smoke

python -m src.assets.feedback_review_smoke \
  --tenant system_default \
  --env prod \
  --project ascension-first-wave \
  --count 8 \
  --output-dir out/feedback-review-smoke \
  --no-redis \
  --json

CAP010 Live Evidence Bridge

CAP010 production /verify-shell data lands in oracle_events_7a first, then bridges into the generic evidence core:

python -m src.oracles.cap010.kv_importer --once --kv-only
python -m src.oracles.cap010.live_bridge \
  --once \
  --source-kind cap010-live \
  --tenant cap010 \
  --env prod \
  --output out/cap010-live-dry-run/bridge-summary.json \
  --json

The bridge keeps plan_id optional, defaults live observed fingerprints to grade_code=1A, and reports missing live fields as warning/gap metrics instead of rejecting the row.

Latest small-sample acceptance:

docs/reports/cap010-creep-live-small-sample-20260604.md
oracle_events_seen=11
observations_inserted=11
observations_deduped_on_rerun=11
rejects_recorded=0
trace_by_sid=RESOLVED

Runtime CAP010 KV read material is supplied by master-key. Default master-key JSON output is artifact-safe and redacted; --include-secret is only for the runtime importer process and must not be recorded in logs or artifacts.

DAR Payment / CAP010 Sandbox E2E

CREEP also carries the sandbox-only contract for DAR-driven payment and CAP010 evidence experiments:

PaymentIntentSandbox
  -> PaymentAuthorizationRequestSandbox
  -> PaymentAuthorizationEventSandbox
  -> optional PaymentReversalEventSandbox
  -> LedgerEntry
  -> AssetEvent
  -> evidence_seed

python -m src.tools.payment_sandbox \
  --intent examples/dar-payment-sandbox/payment-intent.fixture.json \
  --authorization-request examples/dar-payment-sandbox/authorization-request.fixture.json \
  --authorization examples/dar-payment-sandbox/authorization-success.fixture.json \
  --reversal examples/dar-payment-sandbox/reversal-refund-success.fixture.json

The sandbox hardening report is the current local evidence that the contract is ready to feed later VCC readiness gates:

python -m src.tools.payment_sandbox_hardening --json

Provider-shaped sandbox events can be generated without calling a provider:

python -m src.tools.payment_provider_sandbox authorize \
  --intent examples/dar-payment-sandbox/payment-intent.fixture.json \
  --request examples/dar-payment-sandbox/authorization-request.fixture.json \
  --outcome authorized

CAP010 /verify-shell can be checked through a read-only smoke that stores status, bytes, hash, and timing only:

python -m src.tools.cap010_smoke \
  --url https://edge-check.com/verify-shell \
  --requests 5 \
  --timeout-seconds 10

Super Ledger Store Dry-run Projection

CREEP can project a company-level Super Ledger store candidate into ERP asset/evidence primitives without writing production storage:

python -m src.tools.super_ledger_store \
  --candidate examples/super-ledger-store/super-ledger-store-candidate.fixture.json \
  --json

This emits AssetSnapshot, AssetEvent, relationship candidates, an evidence seed, and creep.super_ledger_store_ref.v0. It is the first persistence step for the company-level capability, mission, worklog, health, benchmark, and report-topic ledgers; the future write gate remains separate.

The typed write gate consumes that projection and writes only to Super Ledger staging tables when explicitly allowed:

python -m src.tools.super_ledger_write_gate \
  --projection <super_ledger_store_projection.json> \
  --json

Add --allow-staging-write only after reviewing the projection report. The gate never writes CREEP core asset tables or production report tables.

Read-only query reports can be generated from staging tables or from a local projection artifact:

python -m src.tools.super_ledger_query \
  --query overview \
  --json

python -m src.tools.super_ledger_query \
  --projection <super_ledger_store_projection.json> \
  --query project \
  --project-ref particle-accelerator-control-plane \
  --json

Super Ledger mission/correction records can enter CREEP as candidate evidence through the dry-run mission update gate:

python -m src.tools.super_ledger_mission_update_gate \
  --candidate examples/super-ledger-store/mission-update-gate-candidate.fixture.json \
  --json

The mission update gate remains candidate-only. A green projection may enter the separate typed write gate; it does not perform production CREEP writes.

Real VCC providers, real payment authorization, PAN/CVV storage, CAP010 production delivery actions, and Cloudflare mutations remain outside this sandbox path. The sandbox path now covers allow/block authorization requests, authorized/declined authorization outcomes, refund/void/reversal audit semantics, deterministic ERP IDs, and CAP010 linkage drift checks so VCC provider work can later attach behind a stricter gate.

VCC Provider Readiness

Provider selection is reviewed before provider readiness. It selects a first onboarding target from official-doc candidates but does not call provider APIs or create a live-candidate profile:

python -m src.tools.vcc_provider_selection \
  --candidates examples/dar-payment-sandbox/vcc-provider-candidates.fixture.json

Before any real provider or VCC path opens, CREEP evaluates provider readiness through a provider-neutral contract:

python -m src.tools.vcc_provider_readiness \
  --profile examples/dar-payment-sandbox/vcc-provider-profile.fixture.json \
  --policy examples/dar-payment-sandbox/vcc-gate-policy.fixture.json

The readiness contract requires master-key credential governance, scoped runtime material, redacted artifacts, amount controls, merchant controls, idempotency, reversal support, reconciliation, and a kill switch. It does not call provider APIs or authorize real money.

Stripe Issuing capability evidence can be reviewed as a provider-doc matrix before any credential or provider API call:

python -m src.tools.vcc_capability_matrix \
  --matrix examples/dar-payment-sandbox/stripe-issuing-capability-evidence-matrix.fixture.json

The matrix distinguishes provider-native capabilities from CREEP-enforced realtime authorization boundaries. For example, refund and void are treated as observation/reconciliation capabilities, while merchant controls and kill switch are first implemented through realtime authorization policy plus spending controls.

Tiny real-money readiness can be reviewed without executing a payment:

python -m src.tools.tiny_real_money_readiness \
  --profile examples/dar-payment-sandbox/vcc-provider-live-candidate.fixture.json \
  --policy examples/dar-payment-sandbox/vcc-gate-policy.fixture.json \
  --approval examples/dar-payment-sandbox/tiny-real-money-approval.fixture.json

This review only answers whether a single live authorization could be considered. It does not call a provider or execute money movement.

When readiness is green, CREEP can build the final local-only arming plan for a one-shot live authorization:

python -m src.tools.tiny_live_authorization_plan \
  --profile examples/dar-payment-sandbox/vcc-provider-live-candidate.fixture.json \
  --policy examples/dar-payment-sandbox/vcc-gate-policy.fixture.json \
  --approval examples/dar-payment-sandbox/tiny-real-money-approval.fixture.json

The plan records merchant allowlist, amount cap, kill-switch mode, credential bridge reference, receipt, and reconciliation requirements. It still does not call a provider or execute money movement.

The arming plan can be used to decide a redacted Stripe Issuing realtime authorization probe locally:

python -m src.tools.tiny_live_authorization_decision \
  --plan examples/dar-payment-sandbox/tiny-live-authorization-plan-ready.fixture.json \
  --probe examples/dar-payment-sandbox/stripe-realtime-auth-probe-allow.fixture.json

The decision output includes the Stripe webhook response body shape, but does not send it to Stripe.

A local webhook boundary harness verifies a Stripe-Signature-style test header against the exact raw body before delegating to the same decision:

python -m src.tools.stripe_realtime_webhook_harness \
  --plan examples/dar-payment-sandbox/tiny-live-authorization-plan-ready.fixture.json \
  --raw-body examples/dar-payment-sandbox/stripe-realtime-webhook-allow.raw.json \
  --stripe-signature 't=1700000000,v1=<generated>' \
  --signing-secret local_test_signing_key_not_real

The harness proves the raw-body/signature/delivery boundary without sending a response to Stripe.

A sandbox FastAPI route exercises the same boundary while returning the Stripe response body shape:

POST /api/v1/payment/stripe/realtime-authorization/sandbox

It requires CREEP API auth, Stripe-Signature, and the local-only CREEP_STRIPE_WEBHOOK_TEST_SIGNING_SECRET. It returns {"approved":true,"amount":100} for the allowlisted fixture and {"approved":false} for the merchant-blocked fixture. Signature failures return HTTP 400 before JSON parsing.

A live endpoint skeleton is present but default-closed:

POST /api/v1/payment/stripe/realtime-authorization/live

It does not require CREEP API auth because the Stripe webhook signature is the runtime authentication boundary. The route returns HTTP 503 unless CREEP_STRIPE_LIVE_HANDLER_ENABLED=true and CREEP_VCC_REAL_MONEY_GATE_CLOSEOUT_PATH points to a ready closeout report. It also requires CREEP_STRIPE_WEBHOOK_SIGNING_SECRET to be injected at runtime. This keeps live authorization closed until master-key provider/webhook bridges, receipt, reconciliation, and kill-switch evidence are all green.

Master-key VCC provider doctor output can be converted into a CREEP profile generation report:

python -m src.tools.vcc_profile_from_master_key \
  --doctor-report examples/dar-payment-sandbox/master-key-vcc-stripe-doctor-missing.fixture.json \
  --candidates examples/dar-payment-sandbox/vcc-provider-candidates.fixture.json \
  --policy examples/dar-payment-sandbox/vcc-gate-policy.fixture.json \
  --capability-matrix examples/dar-payment-sandbox/stripe-issuing-capability-evidence-matrix.fixture.json

The current real runtime is expected to stop at credential_bridge_missing until provider.stripe_issuing credential material is imported into master-key.

The next live-handler readiness check separates provider credentials from the Stripe webhook endpoint signing secret:

python -m src.tools.stripe_live_handler_readiness \
  --provider-doctor-report examples/dar-payment-sandbox/master-key-vcc-stripe-doctor-missing.fixture.json \
  --webhook-doctor-report /tmp/master-key-vcc-webhook-doctor.json \
  --plan examples/dar-payment-sandbox/tiny-live-authorization-plan-ready.fixture.json \
  --sandbox-route-smoke-green

Current expected output is decision=missing_evidence until master-key governs both provider.stripe_issuing credential material and the Stripe realtime authorization webhook signing secret.

For fully offline fixture tests, use --webhook-signing-bridge with examples/dar-payment-sandbox/stripe-webhook-signing-bridge-missing.fixture.json.

The final local-only closeout before implementing a live handler combines the provider doctor, webhook doctor, tiny approval, arming plan, and sandbox route smoke:

python -m src.tools.vcc_real_money_gate_closeout \
  --provider-doctor-report /tmp/master-key-vcc-provider-doctor.json \
  --webhook-doctor-report /tmp/master-key-vcc-webhook-doctor.json \
  --candidates examples/dar-payment-sandbox/vcc-provider-candidates.fixture.json \
  --policy examples/dar-payment-sandbox/vcc-gate-policy.fixture.json \
  --capability-matrix examples/dar-payment-sandbox/stripe-issuing-capability-evidence-matrix.fixture.json \
  --approval examples/dar-payment-sandbox/tiny-real-money-approval-stripe.fixture.json \
  --sandbox-route-smoke-green

After the closeout is ready, the final local-only execution gate checks receipt, reconciliation, and kill-switch evidence before a tiny live authorization can be armed:

python -m src.tools.vcc_live_execution_gate \
  --closeout-report examples/dar-payment-sandbox/vcc-real-money-closeout-ready.fixture.json \
  --intent examples/dar-payment-sandbox/payment-intent.fixture.json \
  --authorization-request examples/dar-payment-sandbox/authorization-request.fixture.json \
  --authorization examples/dar-payment-sandbox/authorization-success.fixture.json \
  --reversal examples/dar-payment-sandbox/reversal-refund-success.fixture.json \
  --plan examples/dar-payment-sandbox/tiny-live-authorization-plan-ready.fixture.json \
  --kill-switch-probe examples/dar-payment-sandbox/stripe-realtime-auth-probe-allow.fixture.json

This gate remains local-only. It does not call Stripe, load provider or webhook secret material, execute real money, or send a webhook response.

The final local-only operator arming gate combines master-key doctor reports, the closeout, receipt/reconciliation evidence, and kill-switch evidence:

python -m src.tools.vcc_operator_arming_gate \
  --provider-doctor-report /tmp/master-key-vcc-provider-doctor.json \
  --webhook-doctor-report /tmp/master-key-vcc-webhook-doctor.json \
  --candidates examples/dar-payment-sandbox/vcc-provider-candidates.fixture.json \
  --policy examples/dar-payment-sandbox/vcc-gate-policy.fixture.json \
  --capability-matrix examples/dar-payment-sandbox/stripe-issuing-capability-evidence-matrix.fixture.json \
  --approval examples/dar-payment-sandbox/tiny-real-money-approval-stripe.fixture.json \
  --sandbox-hardening-report /tmp/payment-sandbox-hardening-report.json \
  --sandbox-route-smoke-green \
  --intent examples/dar-payment-sandbox/payment-intent.fixture.json \
  --authorization-request examples/dar-payment-sandbox/authorization-request.fixture.json \
  --authorization examples/dar-payment-sandbox/authorization-success.fixture.json \
  --reversal examples/dar-payment-sandbox/reversal-refund-success.fixture.json \
  --plan examples/dar-payment-sandbox/tiny-live-authorization-plan-ready.fixture.json \
  --kill-switch-probe examples/dar-payment-sandbox/stripe-realtime-auth-probe-allow.fixture.json

Expected decision after provider and webhook materials are governed by master-key:

decision=ready_for_operator_arm

After Stripe materials are imported into master-key, the one-shot CREEP closeout runner can call both master-key doctors and the operator arming gate:

python -m src.tools.vcc_master_key_operator_closeout \
  --mkctl /Users/whip_a/projects/master-key-work/mkctl \
  --candidates examples/dar-payment-sandbox/vcc-provider-candidates.fixture.json \
  --policy examples/dar-payment-sandbox/vcc-gate-policy.fixture.json \
  --capability-matrix examples/dar-payment-sandbox/stripe-issuing-capability-evidence-matrix.fixture.json \
  --approval examples/dar-payment-sandbox/tiny-real-money-approval-stripe.fixture.json \
  --sandbox-route-smoke-green

Hardware Fingerprint Roundtrip Simulation

python -m src.assets.hardware_fingerprint.simulate_roundtrip \
  --tenant system_default \
  --env prod \
  --project ascension-first-wave \
  --count 40 \
  --output-dir out/ascension-sim

Fault injection can be layered on the same roundtrip:

python -m src.assets.hardware_fingerprint.simulate_roundtrip \
  --tenant system_default \
  --env prod \
  --project ascension-first-wave \
  --count 40 \
  --fault-scenario network_timeout \
  --fault-scenario browser_runtime_crash \
  --fault-scenario target_rejected \
  --output-dir out/ascension-sim-faults

燃烧弹 / Burnbag ERP Evaluation

python -m src.evaluation.burnbag run \
  --scenario hardware_fingerprint_ascension_roundtrip \
  --tenant system_default \
  --env prod \
  --project ascension-first-wave \
  --runs 7 \
  --count 40 \
  --output-dir out/evaluation/hf-ascension

For Redis-free local runs:

python -m src.evaluation.burnbag fault-suite \
  --scenario hardware_fingerprint_ascension_roundtrip \
  --tenant system_default \
  --env prod \
  --project ascension-first-wave \
  --count 40 \
  --output-dir out/evaluation/hf-faults \
  --no-redis

Design Rule

Prefer common receipt, workflow, and traceability primitives over source-specific one-off flows.