@yiaany/ghostapi 0.1.9 → 0.2.1

package/docs/fundraising/README.md

@@ -1,87 +0,0 @@
-# GhostAPI Launch And Fundraising Package
-
-**Status as of 2026-08-09:** This package describes a working local release candidate and a proposed customer-validation plan. It does not claim users, revenue, growth, customer quotes, customer outcomes, or a deployed hosted service. The evidence boundary is documented in [metrics-and-evidence.md](metrics-and-evidence.md).
-
-## Category Claim
-
-> Safety and verification infrastructure for software built by AI agents.
-
-GhostAPI starts with a narrow, testable wedge: a local provider simulation runtime plus a Linux-only fail-closed egress boundary and sanitized CI evidence for AI-assisted integration code.
-
-## One-Line Description
-
-GhostAPI helps teams test AI-authored integrations against safe local provider simulations and produce CI evidence that a supported run did not reach production.
-
-## 50-Word Description
-
-GhostAPI is safety and verification infrastructure for software built by AI agents. It simulates selected third-party APIs locally, injects controlled failures, masks secret-shaped data, and on supported Linux hosts runs tests inside a loopback-only network namespace. It produces sanitized CI evidence so reviewers can assess integration behavior before merge.
-
-## Problem And Solution
-
-AI coding agents can write and execute code that creates payments, sends messages, modifies repositories, or calls costly model APIs. A base-URL convention or hand-written mock does not stop a new HTTP client, direct IP call, or subprocess. Teams also need to test ambiguity: `429`, timeouts, duplicate delivery, retries, and idempotency.
-
-GhostAPI gives the integration code a local, provider-shaped test target. On compatible Linux hosts, `ghostapi run` starts the target in a fresh user, mount, network, and PID namespace with loopback only, or refuses to start. CI can then retain a bounded, redacted evidence artifact from the exact run. This is not a guarantee against a hostile host, same-user accessible UNIX control sockets, or every provider behavior.
-
-## Why Now
-
-Coding agents are increasingly able to edit and run integration code in tight loops. That makes external side effects and flaky third-party dependencies part of the code-review surface, rather than a manual testing concern. Existing tools address pieces of the workflow: provider test environments, HTTP mocks, request interception, or CI artifacts. GhostAPI tests whether a combined safety boundary plus deterministic failure evidence is a valuable merge gate.
-
-This is a product hypothesis, not evidence of market demand. The repository has no validated customer interview, weekly CI user, paid pilot, or revenue record as of 2026-08-09.
-
-## Market Framing
-
-GhostAPI is not positioned as "more mocks." It sits between:
-
-- Local API simulation and contract testing for integration development.
-- Agent evaluation and reliability testing for generated code.
-- CI policy evidence for teams that need to review external side-effect risk.
-
-The initial buyer hypothesis is a Platform Engineering, AppSec, Developer Productivity, or AI governance leader at a 10-200 engineer SaaS team with sensitive payments, communications, source-control, or model-provider integrations.
-
-## Competitive Matrix
-
-This table compares published scopes reviewed on 2026-08-09. It is not a benchmark or a claim that competitors cannot build similar functions.
-
-| Category / primary source | Publicly documented focus | GhostAPI's narrow difference | Boundary |
-| --- | --- | --- | --- |
-| Stripe test mode and test clocks | Stripe provides test-mode APIs and test clocks for Stripe behavior. | GhostAPI runs a local Stripe-shaped pack and can combine it with local fault behavior and CI evidence. | GhostAPI does not claim live Stripe parity. |
-| WireMock | HTTP API mocking, stubbing, and simulation. | GhostAPI adds reviewed provider-shaped packs, MCP controls, and a Linux egress-run/evidence workflow. | WireMock is mature and configurable; GhostAPI must prove why this workflow matters. |
-| Mock Service Worker | Network-level request interception with handlers for tests and development. | GhostAPI is a standalone local provider runtime, not browser/app-process interception, and targets agent-controlled integration flows. | MSW remains a strong application-test choice. |
-| Postman | API development, testing, and collaboration around collections/APIs. | GhostAPI focuses on executing application/agent code safely in a local runtime and retaining run evidence. | It is not an API-client replacement. |
-| GitHub Actions artifacts and checks | CI status checks and artifact retention. | GhostAPI supplies an integration-specific, sanitized evidence artifact and policy result. | GitHub remains the CI platform; GhostAPI is a check within it. |
-
-Primary sources: [Stripe test mode](https://docs.stripe.com/test-mode), [Stripe test clocks](https://docs.stripe.com/billing/testing/test-clocks), [WireMock documentation](https://wiremock.org/docs/), [MSW documentation](https://mswjs.io/docs/), [Postman documentation](https://learning.postman.com/docs/), and [GitHub Actions artifacts](https://docs.github.com/actions/using-workflows/storing-workflow-data-as-artifacts). Recheck these links before external publication.
-
-## Moat Thesis
-
-The potential moat is an evidence chain, not a single simulator: one typed workflow should eventually connect local simulation, sanitized record/replay, deterministic evals, CI policy checks, and bounded production-action controls. Provider compatibility fixtures, incident-derived regression scenarios, and deployment into merge gates could compound over time.
-
-This is a thesis, not a current moat. Today, GhostAPI has a local runtime, an early Stripe pack, policy/evidence/eval primitives, and an undeployed hosted-pilot skeleton. It has no demonstrated switching costs, network effects, customer data advantage, or production action gateway.
-
-## Go-To-Market
-
-1. Recruit five tightly qualified paid-pilot candidates, not a broad self-serve funnel.
-2. Lead with one risk: AI-authored Stripe or webhook code running in CI without production credentials or egress proof.
-3. Run a 30-minute discovery call, then offer a fixed-scope, 3-4 week validation pilot only if a buyer owns the risk.
-4. Require one Linux CI workflow, one deterministic failure path, a named technical owner, and a closeout decision.
-5. Publish useful OSS examples and a technical launch only after the exact release commit passes the pinned Linux CI workflow.
-6. Use observed adoption, blocked workflows, and buyer decisions to decide whether shared CI evidence is worth hosted product work.
-
-## Pricing Summary
-
-- **OSS Local:** available, MIT licensed, local-first, and free. It has no account, paywall, or hosted dependency.
-- **Team:** a proposed fixed-scope design-partner pilot, not a generally available plan. No public price is validated.
-- **Enterprise:** discovery only. No hosted deployment, SSO/SCIM, SLA, billing, or production-action service is available for purchase.
-
-See [commercial/pricing.md](../commercial/pricing.md) for the evidence-led pricing experiment and [commercial/manual-invoicing.md](../commercial/manual-invoicing.md) for the manual-pilot boundary.
-
-## Package Index
-
-- [Metrics and evidence boundary](metrics-and-evidence.md)
-- [Three-minute technical demo](demo-script.md)
-- [Launch posts](launch-posts.md)
-- [YC-style application answers](yc-application.md)
-- [50 design-partner targets](design-partners-50.md)
-- [Data room checklist](data-room-checklist.md)
-- [12-month gated roadmap](roadmap-12-month.md)
-- [Technical due diligence index](technical-due-diligence-index.md)

package/docs/fundraising/data-room-checklist.md

@@ -1,72 +0,0 @@
-# Data Room Checklist
-
-Create this room only with founder and counsel review. Do not place provider secrets, raw traffic, production credentials, customer source code, personal data, or unredacted security incidents in it.
-
-## Corporate
-
-- [ ] Certificate of incorporation or formation; jurisdiction and entity type.
-- [ ] Charter, bylaws, operating agreement, and board consents.
-- [ ] Cap table with fully diluted ownership, option pool, SAFEs/notes/warrants, and dates.
-- [ ] Founder stock purchase agreements and vesting/repurchase terms.
-- [ ] Founder, employee, and contractor IP/confidentiality assignment agreements.
-- [ ] Current officer/director list and any investor rights.
-- [ ] Tax registrations, elections, and material tax correspondence.
-
-## Product And IP
-
-- [ ] Repository map, architecture overview, and package boundaries.
-- [ ] License inventory for direct and material transitive dependencies.
-- [ ] OSS license, contributor policy, and third-party notices.
-- [ ] Trademark/domain ownership record, if applicable.
-- [ ] Evidence that contributors assigned or licensed contributed IP appropriately.
-- [ ] List of proprietary datasets, provider contracts, or generated assets, if any.
-
-## Security And Privacy
-
-- [ ] `SECURITY.md`, egress threat model, release-readiness matrix, and incident-response material.
-- [ ] Current dependency audit results with runtime/dev separation and remediation plan.
-- [ ] Secure-development controls: code review, CI, pinned actions, secret scanning, and release checklist.
-- [ ] Data inventory and draft privacy/terms materials clearly labeled as non-operative until counsel approves them.
-- [ ] Product data-flow diagram: local runtime, local evidence, optional local telemetry, and undeployed hosted-pilot boundary.
-- [ ] Disclosure of limitations: Linux-only enforcement, same-user/filesystem limits, heuristic sanitization, and no deployed hosted control plane.
-- [ ] Penetration-test, SOC 2, ISO, or compliance evidence only if actually completed; otherwise state "not completed."
-
-## Commercial And Customer Evidence
-
-- [ ] Dated, sanitized customer discovery ledger with source references.
-- [ ] Signed pilot agreements, LOIs, invoices, purchase orders, or renewals, if any.
-- [ ] Pilot success criteria and closeout reports.
-- [ ] Customer references only with written permission.
-- [ ] Pricing hypotheses, quotes, objections, and conversion outcomes marked as observed vs assumption.
-- [ ] Explicit statement that as of 2026-08-09 this repository contains no verified paid pilot, LOI, customer outcome, or revenue.
-
-## Metrics
-
-- [ ] Metric definitions: activation, weekly CI use, retained team, prevented egress, bug caught, paid pilot, and expansion.
-- [ ] Data-source map and owner for each metric.
-- [ ] Local telemetry export policy and opt-in/opt-out evidence.
-- [ ] Cohort and retention reports only after data is actually collected.
-- [ ] Explanation of metrics unavailable or not measured; never backfill estimates as observed facts.
-
-## Financial Model Inputs
-
-- [ ] Cash balance, burn, runway, headcount/contractor commitments, and material liabilities.
-- [ ] Bottom-up pilot model: target accounts, discovery-to-pilot assumptions, fixed pilot scope, support hours, and delivery cost.
-- [ ] Pricing research ledger, including null/negative outcomes.
-- [ ] Hosting, support, provider, security, legal, insurance, and sales cost assumptions with date/source.
-- [ ] Base, downside, and upside scenarios clearly labeled as assumptions.
-- [ ] No claim of ARR, MRR, gross margin, CAC, LTV, or pipeline without a source and calculation.
-
-## Contracts And Legal
-
-- [ ] Pilot agreement template reviewed by counsel.
-- [ ] Statement of work template: scope, evidence, support boundary, acceptance, confidentiality, and exit.
-- [ ] Data-processing terms, subprocessors, retention/deletion terms, and security addendum only when the service model exists and counsel approves them.
-- [ ] Insurance, export-control, employment, and open-source compliance records as applicable.
-
-## Technical Due Diligence
-
-- [ ] Link to [technical-due-diligence-index.md](technical-due-diligence-index.md).
-- [ ] Release commit SHA and CI evidence from the exact release candidate.
-- [ ] Test/build/package/audit outputs with command, date, environment, and known gaps.
-- [ ] Architecture decisions, threat model, security findings, and remediation status.

package/docs/fundraising/demo-script.md

@@ -1,52 +0,0 @@
-# Three-Minute Technical Demo
-
-## Claim And Limits
-
-Show a reproducible technical demonstration, not a customer result:
-
-> An AI coding agent can write unsafe Stripe integration code; GhostAPI can keep a supported Linux test run off production, make failure paths deterministic, and publish sanitized evidence for review.
-
-Run the enforcement portion only on a compatible Linux runner. Windows and macOS can demonstrate local simulation and MCP behavior controls, but cannot demonstrate `ghostapi run` egress enforcement. Do not run the direct-production-egress fixture outside the enforced Linux boundary.
-
-The current eval runner deliberately does **not** auto-apply declared `injectedFailures`; configure the failures through MCP before the run. This is an operator-orchestrated demo, not one fully automatic command.
-
-## Preflight
-
-1. Use a clean checkout of the proposed release commit on Linux with Node.js 20+, `unshare`, and `iproute2`.
-2. Run `npm ci`, `npm run build`, and `node dist/cli/index.js doctor --egress --json`.
-3. Use a temporary `GHOSTAPI_DATA_DIR`; use only fake Stripe keys.
-4. Prepare a small agent-authored test with three cases: retry a `429` while honoring `Retry-After`, abort a delayed local response, and de-duplicate a pull-delivered Stripe webhook. The existing [Stripe example](../../examples/stripe-node/README.md) demonstrates local duplicate webhook delivery.
-5. Start the GhostAPI MCP server using the checked-out build. Ask the coding agent to configure these deterministic local controls before it writes/runs tests:
-
-```text
-set_api_behavior POST /v1/payment_intents
-  status: 429
-  headers: { retry-after: "1" }
-
-set_api_behavior POST /v1/customers
-  status: 200
-  delayMs: 1500
-```
-
-`delayMs` is bounded to 10 seconds and only delays the specified local behavior. It does not affect a live provider.
-
-## Live Script
-
-| Time | What to show | What to say |
-| --- | --- | --- |
-| 0:00-0:25 | Give the agent the task: create a Stripe Payment Intent helper with retry/idempotency and webhook de-duplication. | "The point is not that the agent can call Stripe. The point is that the test environment makes dangerous and ambiguous behavior visible before merge." |
-| 0:25-0:50 | Show the first agent implementation: it retries after `429` but reuses neither an idempotency key nor timeout-safe state; its webhook handler processes the duplicate twice. | "This is deliberately unsafe demo code, not a production incident." |
-| 0:50-1:20 | Run its test through `ghostapi run --policy ghostapi.policy.yaml -- npm test`. The local 429, delayed response, and duplicate delivery reveal the defects. | "The target has loopback only if Linux preflight succeeds. If preflight fails, GhostAPI refuses to launch it." |
-| 1:20-1:40 | Run the reference blocked-egress regression: `ghostapi run --policy examples/ci-smoke/ghostapi.policy.yaml -- npm --prefix examples/ci-smoke run test:production-egress`. It must exit non-zero. | "This direct `api.stripe.com` attempt is intentionally blocked by the namespace. The current backend does not attribute each kernel-denied socket individually." |
-| 1:40-2:05 | Ask the agent to retain one idempotency key across retry, stop on client timeout, and de-duplicate webhook event IDs. Re-run the local tests. | "The fix is application behavior; GhostAPI exposes the failure path without production credentials or outbound provider calls." |
-| 2:05-2:35 | Run the fixed tests through `ghostapi run` and generate evidence from the exact run: `ghostapi evidence generate --policy ghostapi.policy.yaml --run <run.json> --out ghostapi-evidence.json --ci`. | "The evidence is bounded and redacted. It is the review record, not raw request logs." |
-| 2:35-3:00 | Show the `Enforced safety check` status and uploaded artifact using the reference [PR workflow](../github-actions.md). | "The claim is narrow: this supported run passed its policy with zero recorded production attempts. It is not a general host sandbox, hosted service, or absolute safety guarantee." |
-
-## Expected Outcomes
-
-- The unsafe implementation's unit/integration assertions fail on `429`, timeout, or duplicate webhook handling.
-- The direct-production-egress fixture exits non-zero only within a successful Linux namespace run.
-- The corrected implementation's local tests pass.
-- The fixed CI run produces a sanitized evidence artifact and passes the chosen policy.
-
-Do not claim that GhostAPI automatically discovered the bug, injected eval-declared failures by itself, prevented a real production incident, or proves every route from an agent to the internet is impossible.

package/docs/fundraising/design-partners-50.md

@@ -1,74 +0,0 @@
-# 50 Design-Partner Targets
-
-This is an account list for research and outreach, not evidence that any company is interested, uses AI coding agents, has the required provider stack, or has been contacted. Do not infer a personal contact from this list. Before outreach, verify the current engineering size, relevant integration risk, public AI-development posture, and appropriate Platform/AppSec/Developer Productivity/Engineering leader through public company channels.
-
-## Qualification Criteria
-
-- B2B SaaS or developer-facing company with an externally integrated product.
-- Plausible risk from payments, communications, source-control, webhooks, cloud APIs, or model-provider APIs.
-- Likely ability to run one compatible Linux CI workflow.
-- A team that can name a technical owner and a buyer for a 3-4 week fixed-scope pilot.
-
-## Targets
-
-| # | Account | Segment | Why It May Fit | Outreach Thesis |
-| ---: | --- | --- | --- | --- |
-| 1 | Vercel | Developer platform | Agent-assisted development and deployment integrations. | Can a CI artifact improve review of agent-authored integration code? |
-| 2 | Sentry | Developer tooling | Error, alerting, and webhook integrations. | Test retries and external notifications without live side effects. |
-| 3 | PostHog | Product analytics | Event, webhook, and developer-platform workflows. | Make integration failures repeatable in CI. |
-| 4 | Render | Cloud platform | Customer-facing provisioning and API workflows. | Validate agent-authored API clients against bounded failures. |
-| 5 | Railway | Cloud platform | Deployment and API-heavy developer workflows. | Test agent changes without reaching production services. |
-| 6 | Fly.io | Cloud platform | Infrastructure APIs and release automation. | Review egress and failure behavior before merge. |
-| 7 | Supabase | Backend platform | Auth, database, webhook, and API ecosystems. | Exercise client retries and webhook validation locally. |
-| 8 | Clerk | Identity platform | Auth and webhook integration risk. | Verify duplicate deliveries and failure handling in CI. |
-| 9 | Auth0 | Identity platform | Security-sensitive identity integrations. | Establish deterministic negative-path evidence. |
-| 10 | WorkOS | Enterprise identity | Webhook and directory-sync integrations. | Test high-risk callbacks without live tenant data. |
-| 11 | LaunchDarkly | Feature management | SDK and webhook-heavy platform surface. | Gate agent-authored integration tests on evidence. |
-| 12 | Datadog | Observability | Alerting and API integrations. | Test rate limits and retries without production calls. |
-| 13 | New Relic | Observability | Instrumentation and notification integrations. | Identify whether local evidence changes review workflow. |
-| 14 | Honeycomb | Observability | Event and API-driven engineering teams. | Evaluate deterministic failure testing for agents. |
-| 15 | Grafana Labs | Observability | Plugins, alerts, and external service integrations. | Test outbound boundaries in contributor/CI flows. |
-| 16 | PagerDuty | Incident response | External notification and automation risk. | Reproduce failed notification and retry behavior safely. |
-| 17 | Incident.io | Incident response | Slack, webhook, and automation workflows. | Test duplicate event and timeout recovery paths. |
-| 18 | Linear | Collaboration software | GitHub and notification integrations. | Evaluate safe integration changes authored by agents. |
-| 19 | Notion | Collaboration software | API and webhook ecosystem. | Test agent changes against local provider-shaped boundaries. |
-| 20 | Airtable | Workflow platform | Automation and third-party API workflows. | Test deterministic error handling before merge. |
-| 21 | Zapier | Automation platform | Multi-provider side-effect risk. | Pick one workflow where egress evidence changes a release decision. |
-| 22 | n8n | Workflow automation | User-configured external integrations. | Test agent-generated nodes without provider credentials. |
-| 23 | Retool | Internal-tools platform | Customer API connections and agent-assisted builds. | Enforce a safe test target for generated integrations. |
-| 24 | Temporal | Workflow orchestration | Retry, timeout, and idempotency-heavy workflows. | Validate integration behavior under controlled ambiguity. |
-| 25 | Airbyte | Data integration | Connector and external API reliability risk. | Test connector behavior with bounded local scenarios. |
-| 26 | Fivetran | Data integration | Provider APIs, auth, and retry semantics. | Explore a reproducible failure-evidence workflow. |
-| 27 | Pipedream | Developer automation | Code steps calling many provider APIs. | Keep agent-authored tests out of production by default. |
-| 28 | Algolia | Search platform | SDK and webhook/API customer integrations. | Test provider failures and evidence artifacts in CI. |
-| 29 | Amplitude | Product analytics | Event ingestion, API, and integration surface. | Validate one agent-generated client failure path before merge. |
-| 30 | Snyk | Developer security | AppSec buyer overlap and CI-native workflows. | Assess whether evidence adds value beyond code scanning. |
-| 31 | Semgrep | Developer security | CI policy and AI-code review focus. | Test a complementary runtime-evidence workflow. |
-| 32 | Sonar | Code quality | AI-generated-code review focus. | Determine whether integration evidence complements static checks. |
-| 33 | GitLab | DevOps platform | CI, security, and integration ecosystem. | Explore a narrow CI evidence pilot, not a platform replacement. |
-| 34 | CircleCI | CI platform | CI-native customer base and external integrations. | Test whether a reusable safety check is valuable to users. |
-| 35 | Harness | Delivery platform | Policy and controlled automation use cases. | Validate egress evidence around one AI-assisted workflow. |
-| 36 | Buildkite | CI platform | Engineering teams with flexible CI environments. | Qualify Linux enforcement and artifact retention needs. |
-| 37 | HashiCorp | Infrastructure software | API-driven provisioning and security-sensitive workflows. | Assess a narrowly scoped egress/evidence workflow. |
-| 38 | Stripe | Payments platform | Payment lifecycle and developer test workflows. | Explore local deterministic payment-failure evidence. |
-| 39 | Paddle | Payments platform | Billing and webhook integrations. | Test duplicate delivery and idempotency paths in CI. |
-| 40 | Adyen | Payments platform | High-stakes payment integrations. | Qualify whether local simulation adds value to existing test tools. |
-| 41 | Plaid | Financial data APIs | Sensitive API and webhook workflows. | Test safe failure/retry behavior without live access. |
-| 42 | Mercury | Fintech | Banking workflow side-effect sensitivity. | Validate whether evidence alters one release decision. |
-| 43 | Brex | Fintech | Spend and payment integrations. | Explore bounded agent integration testing with no production credentials. |
-| 44 | Rippling | HR platform | Payroll, identity, and integration complexity. | Test webhook and external workflow failure paths. |
-| 45 | Gusto | HR/payroll | High-consequence external integrations. | Qualify one non-production CI workflow only. |
-| 46 | Webflow | SaaS platform | API, app ecosystem, and automation workflows. | Test agent-authored apps/integrations before merge. |
-| 47 | Intercom | Customer communications | Messaging/webhook side-effect risk. | Test retries, rate limits, and no-live-send workflow. |
-| 48 | Twilio | Communications platform | Messaging API and webhook ecosystem. | Exercise agent-generated integration failures locally. |
-| 49 | Resend | Email platform | Email-send integration and developer experience. | Test no-live-send and retry evidence in CI. |
-| 50 | ElevenLabs | AI platform | API usage, spend, and model-provider integration risk. | Test agent code against local provider-shaped responses. |
-
-## Outreach Sequence To Five Paid-Pilot Decisions
-
-1. Research 50 accounts and select 20 that meet all four qualification criteria.
-2. Send 20 concise role-based outreach notes asking for a 20-minute discovery call about one existing integration review or failure path; do not claim a customer result.
-3. Run 10 discovery calls using [the question set](../design-partners/discovery-questions.md). Record only a dated, sanitized private summary.
-4. Invite the 5 strongest fits to a live technical demo and ask each for a binary pilot decision, named owner, one Linux CI workflow, and a 3-4 week time commitment.
-5. Offer a written fixed-scope paid-pilot proposal only where the buyer confirms a budget process and measurable success criteria. Count a decision of "no," "later," or "OSS only" as a valid outcome; do not convert interest into traction.
-6. Target outcome: five paid-pilot **decisions**, not five fabricated contracts. Success is at least one signed paid pilot or a documented reason to reshape the wedge.

package/docs/fundraising/launch-posts.md

@@ -1,37 +0,0 @@
-# Launch Posts
-
-Use only after the exact release commit has passed the pinned Linux CI workflow. Replace bracketed fields with verified facts or remove them. Do not add customer, revenue, install, or performance claims without a dated source.
-
-## Hacker News: Show HN
-
-**Title:** Show HN: GhostAPI - local API simulation and CI evidence for AI-authored integrations
-
-**Post:**
-
-I built GhostAPI because AI coding agents can write and run integration code, but a base URL and a mock alone do not show reviewers whether a test touched production or exercised failure paths.
-
-GhostAPI runs provider-shaped APIs locally, exposes deterministic controls through MCP, masks secret-shaped values, and on compatible Linux hosts can run a target in a loopback-only namespace. It can produce a sanitized evidence artifact for CI.
-
-The first deep provider pack is Stripe-shaped local simulation. The repo includes examples for `429`, delayed responses, duplicate webhook delivery, policy checks, record/replay, and a GitHub Actions reference workflow.
-
-Important limits: Linux enforcement requires `unshare` and `iproute2` preflight; Windows/macOS do not have equivalent process enforcement. This is not a hostile-code filesystem sandbox or a hosted service.
-
-I am looking for teams that use coding agents on Stripe/webhook/integration code and can test one CI workflow. What failure path or review decision would make an artifact like this useful?
-
-## Reddit
-
-**Title:** I made a local safety/evidence layer for AI-authored API integrations. Looking for harsh feedback.
-
-AI coding agents make it easier to create integration code, but they also make it easier to run tests that call real providers or skip retry/idempotency edge cases. GhostAPI is an OSS local runtime that simulates selected APIs, lets an agent configure deterministic failures through MCP, and creates a sanitized CI artifact.
-
-On supported Linux hosts, `ghostapi run` uses a loopback-only namespace and fails closed if it cannot create it. On Windows/macOS it is local simulation only, not egress enforcement.
-
-I am not claiming traction or a hosted enterprise product. I want feedback from engineers who have had to review AI-authored Stripe, webhook, email, or model-provider code: would a reproducible `429`/timeout/duplicate-delivery test plus CI evidence change your merge process? What would make it unusable?
-
-## X / LinkedIn
-
-AI coding agents can write integration code. The harder question is how a team proves that agent-authored tests stayed off production and exercised the failure paths that cause duplicate payments, bad retries, or unsafe webhooks.
-
-GhostAPI is an OSS local runtime for that narrow problem: provider-shaped simulation, MCP-controlled deterministic failures, secret masking, and Linux-only fail-closed egress runs with sanitized CI evidence.
-
-No hosted service or customer traction claims yet. I am recruiting teams willing to validate one real CI workflow around Stripe, webhooks, or other high-risk integrations.

package/docs/fundraising/metrics-and-evidence.md

@@ -1,30 +0,0 @@
-# Metrics And Evidence Boundary
-
-Reviewed on 2026-08-09 from `SESSION_LOG.md`, the local CLI telemetry export, and repository verification records.
-
-| Metric | Observed value | Source | Classification |
-| --- | ---: | --- | --- |
-| Root test suite | 225 passing; 8 Linux-only namespace tests skipped on Windows | Session 22, 2026-08-09 | Development verification, not customer traction |
-| WSL Linux test suite | 232 passing; 1 optional test skipped | Session 22, 2026-08-09; Ubuntu WSL 2, Node.js 20.20.2, Linux filesystem copy | Development verification, not customer traction |
-| Linux CI smoke demonstration | Safe run generated PASS evidence; direct `api.stripe.com` fixture failed inside the namespace as expected | Session 22, 2026-08-09 | Reproducible technical demo, not customer outcome |
-| Linux enforced full suite | `ghostapi run -- npm test` completed in 48.75 seconds and generated PASS exact-run evidence | Session 22, 2026-08-09; Ubuntu WSL 2, Node.js 20.20.2 | Development verification, not a first-value benchmark or customer traction |
-| Hosted-pilot tests | 7 passing | Session 21, 2026-08-08 | Development verification only |
-| CI design partners | 0 | `SESSION_LOG.md` metrics table, 2026-08-04 | Observed status |
-| Paying design partners | 0 | `SESSION_LOG.md` metrics table, 2026-08-04 | Observed status |
-| Weekly active projects | Not measured | `SESSION_LOG.md` metrics table | Unknown |
-| Prevented production egress attempts | Not measured | `SESSION_LOG.md` metrics table | Unknown |
-| Confirmed bugs caught before merge | Not measured | `SESSION_LOG.md` metrics table | Unknown |
-| Local telemetry counters | all zero; telemetry disabled | `ghostapi telemetry export --json`, 2026-08-09 | Local state; not an install/user metric |
-| Windows local onboarding measurement | 3.03 seconds | `docs/development/onboarding-smoke.md`, 2026-08-08 | Single-host simulation measurement, not Linux enforcement or public benchmark |
-
-## Rules For External Materials
-
-- Label a demo as a demo. It is not a prevented incident, customer outcome, or benchmark.
-- Label every future number as a **target** or **assumption** with a date and owner.
-- Do not infer active users from package downloads, GitHub stars, local telemetry, workflow runs, or conversations.
-- Do not use an old repository statement as customer proof without a dated, sanitized primary record.
-- Do not claim an enforcement result from Windows or macOS. `ghostapi run` must succeed on a compatible Linux host, and the resulting evidence must be retained.
-
-## Current Release Evidence
-
-Session 22 additionally ran the full namespace suite and CI smoke workflow locally in Ubuntu WSL 2 on Node.js 20.20.2. The safe fixture produced PASS evidence with a completed Linux namespace boundary, one allowed local Stripe-shaped request, zero production attempts, no secret categories, and the required scenario. The direct `api.stripe.com` fixture failed as expected inside the loopback-only namespace. This does not substitute for the pinned GitHub Linux workflow on the exact release commit before external publication. See [release-readiness.md](../release-readiness.md).

package/docs/fundraising/roadmap-12-month.md

@@ -1,25 +0,0 @@
-# 12-Month Gated Roadmap
-
-This roadmap is a decision framework, not a promise of delivery or revenue. Dates are relative to the first verified external release. Every milestone requires the listed evidence; absence of evidence blocks expansion.
-
-| Period | Milestone | Evidence Required | Do Not Do Yet |
-| --- | --- | --- | --- |
-| Month 0 | Release candidate proof | Pinned GitHub Linux CI passes on the exact commit; sanitized artifact reviewed; package smoke and production dependency audit pass. | Do not call Windows local simulation an egress-enforcement result. |
-| Months 1-2 | 20 discovery conversations | Dated, sanitized notes using the design-partner questions; clear segment/risk/buyer patterns. | Do not infer demand from downloads, stars, or polite feedback. |
-| Months 2-3 | Five pilot decisions | Each decision has a named workflow, owner, buyer response, and privacy-safe evidence record. | Do not build self-serve billing, entitlement, or a general hosted service. |
-| Months 3-4 | One Linux CI design-partner workflow | Weekly runs for two consecutive weeks plus a reviewed artifact or documented blocker. | Do not claim retention from installation. |
-| Months 4-6 | One confirmed value outcome | A customer-sourced, dated record of a merge/release decision changed, prevented egress supported by evidence, or real integration defect caught before merge. | Do not publish a ROI claim before a source exists. |
-| Months 4-6 | Close remaining local proof gaps | Automatic typed failure-plan/scenario receipts, added Stripe conformance only where a partner needs it, and Vite/Vitest audit migration in a dedicated compatibility change. | Do not widen providers just for logo coverage. |
-| Months 6-8 | Paid-pilot decision | Signed fixed-scope pilot or explicit documented rejection after proposal; agreed success criteria and manual invoice boundary. | Do not add card collection or subscription infrastructure without a repeatable paid workflow. |
-| Months 8-10 | Team-control-plane decision | At least two partners show the same shared evidence/policy workflow and staging operations prove hosted controls. | Do not offer the current undeployed hosted skeleton. |
-| Months 10-12 | Product focus decision | Retention, value, and willingness-to-pay evidence support either CI/shared-evidence focus, a revised wedge, or stopping the expansion. | Do not build production-action gateway, credential broker, or broad enterprise surface without a validated workflow and stronger security model. |
-
-## Confirmed Risks Driving This Roadmap
-
-- Exact-release GitHub Linux CI proof is outstanding.
-- Local Linux enforcement is verified in Ubuntu WSL 2, but the pinned GitHub workflow has not run on the exact release commit.
-- Automatic application of eval-declared failures and scenario completion receipts is not implemented.
-- Stripe compatibility is limited to implemented local capabilities, not live-provider parity.
-- The hosted pilot remains undeployed; auth, migrations, queues, load, and disaster recovery are unverified.
-- The full dependency audit retains five development-only Vite/Vitest/esbuild findings pending a separate breaking migration.
-- No customer evidence validates the proposed paid/team wedge.

package/docs/fundraising/technical-due-diligence-index.md

@@ -1,37 +0,0 @@
-# Technical Due Diligence Index
-
-## Product Runtime
-
-- [Root README](../../README.md): quickstart, local capabilities, platform support, and safety limits.
-- [Usage guide](../usage.md): commands, policy, evidence, eval, record/replay, contracts, and telemetry.
-- [Provider authoring](../providers/authoring-packs.md): provider-pack boundary and conformance model.
-- [Stripe pack](../providers/stripe-core-pack.md): implemented Stripe-shaped capabilities and limits.
-
-## Security
-
-- [Security policy](../../SECURITY.md)
-- [Egress threat model](../security/egress-threat-model.md)
-- [Policy as code](../policy.md)
-- [Release readiness](../release-readiness.md)
-- [Release migration and rollback](../release-migration-and-rollback.md)
-- [Release checklist](../release-checklist.md)
-
-## CI And Evidence
-
-- [GitHub Actions PR safety check](../github-actions.md)
-- [Generic CI guide](../ci.md)
-- [Reference workflow](../../.github/workflows/ghostapi-pr-safety.yml)
-- [CI smoke fixture](../../examples/ci-smoke/README.md)
-- [Agent eval example](../../examples/evals/README.md)
-
-## Architecture And Operations
-
-- [Team-control-plane prototype](../team-control-plane.md): local-only model and security boundaries.
-- [Hosted pilot](../hosted-pilot.md): undeployed architecture and deployment gates.
-- [Design-partner validation kit](../design-partners/README.md)
-- [Commercial readiness](../commercial/README.md)
-- [Session log](../../../SESSION_LOG.md): chronological implementation and verification history; verify against source and Git history.
-
-## Verification Snapshot
-
-Session 22 on 2026-08-09 passed the Windows root suite (225 passed, 8 Linux-only skips), typecheck, build, packed-package smoke, and production dependency audit. It also passed the Linux root suite in Ubuntu WSL 2 on Node.js 20.20.2 (232 passed, 1 optional skip), including the namespace egress suite and an actual safe-evidence/blocked-egress CI smoke run. The pinned GitHub Linux CI workflow still must run on the exact external release commit before publication. Full development dependency audit remains open for five Vite/Vitest/esbuild findings. See [metrics-and-evidence.md](metrics-and-evidence.md) and [release-readiness.md](../release-readiness.md).

package/docs/fundraising/yc-application.md

@@ -1,25 +0,0 @@
-# YC-Style Answers
-
-Replace every bracketed field with founder-provided, independently confirmable information. Do not submit placeholders.
-
-| Question | Draft answer |
-| --- | --- |
-| What is your company going to make? | GhostAPI is safety and verification infrastructure for software built by AI agents. It starts as a local provider simulation runtime with deterministic failure controls and, on compatible Linux hosts, a fail-closed test-run boundary plus sanitized CI evidence. |
-| What is your product? | Developers point integration code at local provider-shaped APIs, configure failures through MCP, run tests through a versioned policy, and retain a bounded evidence artifact for review. The current local product supports selected providers; Stripe is the deepest pack. |
-| Where do you live now and where will the company be based after YC? | [Founder-provided location and intended company location.] |
-| Why did you pick this idea? | [Founder-provided first-hand observation. Do not invent a prior incident.] The product hypothesis is that teams need evidence and failure testing for agent-authored integration code, not another generic mock server. |
-| How far along are you? | The repository has a tested local runtime, policy/evidence/eval primitives, Stripe-shaped local workflows, a GitHub Actions reference check, and an undeployed hosted-pilot skeleton. The current evidence record has zero CI design partners and zero paying partners; no revenue or retention is claimed. |
-| How long have you worked on this? | [Founder-provided dates and full-time/part-time status.] |
-| Are people using it? | No validated usage claim is available as of 2026-08-09. The next goal is five paid-pilot decisions, beginning with one selected Linux CI workflow per team. |
-| Do you have revenue? | No revenue is documented in the repository as of 2026-08-09. |
-| Who are the competitors? | Provider test environments, WireMock, MSW, Postman, and CI-native checks each cover adjacent jobs. GhostAPI's hypothesis is that agent-native local simulation plus supported egress enforcement and evidence is a useful combined workflow. See [the competitor matrix](README.md#competitive-matrix). |
-| How will you make money? | Keep the local OSS runtime free. Validate a fixed-scope paid pilot for protected CI workflows and retained sanitized evidence before naming a recurring price. Hosted team/enterprise controls are not currently available. |
-| Why now? | Coding agents can create and run more integration code autonomously, increasing the need to make external side effects and failure handling reviewable. This is a timing hypothesis, not a quantified market claim. |
-| Founder video / bios | [Founder names, roles, education, employment history, technical work, and relevant domain experience. Use only facts the founders approve.] |
-| Equity split | [Founder-provided current split and rationale.] |
-| Have you incorporated? | [Founder-provided jurisdiction, entity type, incorporation date, or "not incorporated".] |
-| Fundraising | [Founder-provided prior funding, current raise, runway, and investor names if disclosure is appropriate.] |
-
-## One-Minute Spoken Pitch
-
-AI agents now write and run code that touches payments, email, GitHub, and model APIs. Teams can point SDKs at a mock, but that does not prove an agent did not create another client, call a direct IP, or skip the timeout and duplicate-delivery cases that break integrations. GhostAPI creates a local provider-shaped test world, lets the agent configure deterministic failures, and on supported Linux runs the test with loopback only. CI keeps a sanitized artifact from that exact run. We are early: the code exists, but we have no validated customers or revenue. We are looking for design partners whose merge process would change if they could prove this for one high-risk workflow.

package/docs/hosted-pilot.md

@@ -1,111 +0,0 @@
-# Hosted Pilot Architecture
-
-## Scope And Truthful Guarantees
-
-The hosted pilot is a separate Bun/Elysia application under `hosted/`. The existing Node.js local runtime remains account-free and does not communicate with the hosted service by default.
-
-The design targets 1,000 sustained and 5,000 peak API requests per second, with CI report ingestion and scenario reads as the first workflows. These are capacity targets to prove with production-shaped load tests, not current guarantees.
-
-Supabase read replicas are asynchronous and read-only. All writes use one primary region, and immediate reads after a write also use that primary. Fly may run stateless API instances near clients later, but it must not claim multi-region writes while Supabase has one writable primary. Supabase PITR supports fine-grained recovery, but restoration takes the project offline and duration depends on database size; this stack does not prove RPO under one minute or RTO under five minutes until a vendor-supported configuration and repeated DR drills demonstrate both.
-
-## Architecture
-
-```mermaid
-flowchart LR
-  CI[CI runner or agent] -->|ingest key + idempotency key| API[Bun + Elysia write API]
-  Agent[Agent] -->|session| API
-  API --> Primary[(Supabase PostgreSQL primary)]
-  API --> Redis[Upstash Redis: rate limits + cache only]
-  Primary --> Outbox[Transactional outbox]
-  Dispatcher[Outbox dispatcher] --> QStash[Upstash QStash]
-  QStash --> Worker[Elysia internal worker]
-  Worker --> Primary
-  Reader[Scenario reader] --> API
-  API --> Primary
-```
-
-Redis is deliberately not the source of truth for reports, authorizations, idempotency, or job completion. QStash is at-least-once transport only. PostgreSQL owns durable acceptance, idempotency, outbox state, job receipts, scenario registry, report state, and audit data.
-
-The migration enables RLS on the application tables. The hosted API uses a dedicated least-privilege `service_role` database role with explicit policies; browsers never receive that connection string. Tenant filtering remains explicit in every API query, so authorization does not rely on a future client-side `set_config` convention.
-
-## Request Paths
-
-### Report Intake
-
-`POST /v1/projects/:projectId/reports` requires:
-
-- `Authorization: Bearer <CI ingest secret>`
-- `X-GhostAPI-Ingest-Key-Id: <public UUID>`
-- `Idempotency-Key: <16-256 character key>`
-
-The API hashes the canonical request. In one primary-Postgres transaction it validates the key, creates or resolves the idempotency ledger entry, writes the bounded sanitized report, and writes an outbox event. Only then does it respond with `202 Accepted`.
-
-If the API crashes after commit but before replying, the CI runner retries with the same idempotency key and receives the original report id. If the same key has a different body, it receives `409`.
-
-### CI Ingest Keys
-
-Project developers provision a key with `POST /v1/projects/:projectId/ingest-keys` and an `expiresInDays` value from 1 to 90. The response returns an id, non-sensitive prefix, expiry, and a plaintext secret exactly once. Only the SHA-256 digest is written to PostgreSQL. Developers revoke a key with `POST /v1/projects/:projectId/ingest-keys/:keyId/revoke`; create and revoke actions write tenant audit events. The dashboard/client must not persist, log, or re-display the plaintext secret.
-
-### Scenario Reads
-
-Scenario versions are immutable. Publishing creates a new `{ scenario_key, version }` row. CI runs pin a scenario version; agents read by key/version or a selected current version. Cursor pagination and a read cache belong at the API edge only after primary-query correctness is load-tested.
-
-Read endpoints that must observe a preceding write go to the primary and return `X-Consistency: primary`. A future replica endpoint may return `X-Consistency: eventual`; it cannot back read-your-writes behavior.
-
-### Workers
-
-Outbox dispatch uses `FOR UPDATE SKIP LOCKED`, leases a bounded batch, then publishes an event id to QStash. The QStash receiver verifies the request signature before parsing its body. The worker transaction creates a permanent `job_receipts` record and performs report processing atomically. Redelivery returns a duplicate success without duplicating scenario results.
-
-The dispatcher can publish the same event more than once after an ambiguous network outcome. That is intentional: QStash deduplication has a limited window, so the permanent PostgreSQL receipt is the correctness boundary. A redelivery while an unexpired worker lease is active returns a retryable `503`; a stale lease can be safely acquired again. A completed receipt returns success without duplicating results.
-
-## PostgreSQL Data Model
-
-`hosted/migrations/001_core.sql` creates:
-
-| Table | Purpose |
-| --- | --- |
-| `app.organizations`, `app.organization_memberships`, `app.projects` | Tenant hierarchy and membership. |
-| `app.scenario_versions` | Immutable shared scenario definitions with checksum. |
-| `app.ci_ingest_keys` | Public id plus SHA-256-only CI secret digest and scope. |
-| `app.reports` | Bounded sanitized CI report payload and processing state. |
-| `app.idempotency_ledger` | Durable `(project_id, key)` replay contract. |
-| `app.outbox_events` | Transactional event publication source. |
-| `app.job_receipts`, `app.scenario_run_results` | At-least-once worker deduplication and results. |
-| `app.audit_events` | Hosted control-plane audit metadata. |
-
-Better Auth manages its own `auth` schema/tables through its migration CLI. Configure `AUTH_DATABASE_URL` with `search_path=auth`; application `DATABASE_URL` should use `search_path=app`. Keep application memberships separate from Better Auth accounts so a later SAML/OIDC identity mapping does not rewrite tenant authorization.
-
-## Queue And Rate Limits
-
-- Queue only identifiers and schema version, never raw report JSON, authorization headers, cookies, or provider credentials.
-- Do not use a single FIFO queue. Shard flow-control keys by report/project as needed; workers make every handler idempotent.
-- Verify QStash signatures on every internal job request.
-- Redis keys are opaque non-secret project/principal identifiers, not bearer tokens, email addresses, or raw session ids. The default CI key budget is 300,000 requests per minute per project only as a pilot starting point; derive final limits from tenant budgets and load tests.
-- Rate limits must cover unauthenticated auth routes, CI ingest key id, user/organization, project, and QStash worker endpoint separately.
-- Do not enable automatic retries for non-idempotent external effects. Scenario processing remains local metadata until a typed action gateway exists.
-
-## Capacity Plan
-
-At 1,000 sustained writes per second, report size and retention determine cost and storage more than framework choice. Before accepting pilot load, measure actual p50/p95/p99 report bytes, write/read ratio, tenant count, retention requirements, index growth, WAL throughput, database pool waits, QStash backlog, and worker drain rate.
-
-Initial deployment is one API write region co-located with the Supabase primary, with at least two Fly machines. Use bounded database pools per machine and Supavisor transaction pooling. Add read replicas only after primary query/index behavior is correct and clients tolerate eventual consistency.
-
-## Required Pre-Launch Tests
-
-1. Kill the API after Postgres commit but before response; retry must return one report id and one outbox event.
-2. Force QStash redelivery and worker failure; expect one job receipt and one scenario result per report/version.
-3. Soak 1,000 sustained RPS and burst 5,000 peak RPS using production p99 payloads; verify intake p95/p99, pool waits, WAL, queue depth, worker drain, and zero lost accepted report ids.
-4. Verify primary read-your-writes and clearly labeled replica staleness.
-5. Run a production-equivalent DR drill. Reject the stated RPO/RTO target until observed accepted-data loss is below 60 seconds and restored write availability is below 5 minutes.
-6. Run authorization tests for every organization/project boundary, disabled/revoked ingest key, expired session, body/key mismatch, and direct worker invocation without a valid QStash signature.
-
-## Identity
-
-The hosted app mounts Better Auth for Google OAuth and email/password. Better Auth owns authentication accounts/sessions; GhostAPI owns organization membership and authorization. A later enterprise identity layer maps a verified OIDC/SAML subject to an internal user id. It must not accept arbitrary issuer, email-domain, or client-provided role claims.
-
-## Sources Checked 2026-08-08
-
-- Elysia validation and handler status behavior: official Elysia documentation.
-- Better Auth PostgreSQL and Elysia integration: official Better Auth documentation.
-- Supabase read replicas and PITR recovery limits: official Supabase documentation.
-- QStash deduplication, publish, receiver verification, and at-least-once guidance: official Upstash documentation.