@yiaany/ghostapi 0.1.8 → 0.2.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (293) hide show
  1. package/CHANGELOG.md +21 -0
  2. package/CONTRIBUTING.md +132 -119
  3. package/LICENSE +21 -21
  4. package/PROVENANCE.md +13 -0
  5. package/README.md +78 -80
  6. package/SECURITY.md +56 -53
  7. package/dist/actions/gateway.js +320 -72
  8. package/dist/actions/gateway.js.map +1 -1
  9. package/dist/actions/index.d.ts +2 -2
  10. package/dist/actions/index.js +1 -1
  11. package/dist/actions/index.js.map +1 -1
  12. package/dist/agents/agentPrompt.js +7 -5
  13. package/dist/agents/agentPrompt.js.map +1 -1
  14. package/dist/ai/aiClient.js +5 -5
  15. package/dist/ai/aiClient.js.map +1 -1
  16. package/dist/ai/aiGenerator.js +66 -26
  17. package/dist/ai/aiGenerator.js.map +1 -1
  18. package/dist/ai/genericInference.js +151 -36
  19. package/dist/ai/genericInference.js.map +1 -1
  20. package/dist/ai/prompts.js +55 -49
  21. package/dist/ai/prompts.js.map +1 -1
  22. package/dist/approvals/approvalInbox.js +649 -133
  23. package/dist/approvals/approvalInbox.js.map +1 -1
  24. package/dist/approvals/index.d.ts +2 -2
  25. package/dist/approvals/index.js +1 -1
  26. package/dist/approvals/index.js.map +1 -1
  27. package/dist/behavior/behaviorStore.js +34 -14
  28. package/dist/behavior/behaviorStore.js.map +1 -1
  29. package/dist/cache/index.js +14 -5
  30. package/dist/cache/index.js.map +1 -1
  31. package/dist/cli/index.js +226 -93
  32. package/dist/cli/index.js.map +1 -1
  33. package/dist/cli/openUrl.js +17 -3
  34. package/dist/cli/openUrl.js.map +1 -1
  35. package/dist/cli/parser.js +79 -18
  36. package/dist/cli/parser.js.map +1 -1
  37. package/dist/config/dataPaths.js +4 -2
  38. package/dist/config/dataPaths.js.map +1 -1
  39. package/dist/config/localConfig.js +5 -2
  40. package/dist/config/localConfig.js.map +1 -1
  41. package/dist/config/serverConfig.js +11 -5
  42. package/dist/config/serverConfig.js.map +1 -1
  43. package/dist/contracts/contract.js +311 -83
  44. package/dist/contracts/contract.js.map +1 -1
  45. package/dist/contracts/index.d.ts +2 -2
  46. package/dist/contracts/index.js +1 -1
  47. package/dist/contracts/index.js.map +1 -1
  48. package/dist/credentials/credentialBroker.js +391 -79
  49. package/dist/credentials/credentialBroker.js.map +1 -1
  50. package/dist/credentials/index.d.ts +2 -2
  51. package/dist/credentials/index.js +1 -1
  52. package/dist/credentials/index.js.map +1 -1
  53. package/dist/dashboard/app.js +823 -685
  54. package/dist/dashboard/dashboard.js.map +1 -1
  55. package/dist/dashboard/index.html +704 -267
  56. package/dist/dashboard/styles.css +1040 -349
  57. package/dist/egress/capabilities.js +55 -25
  58. package/dist/egress/capabilities.js.map +1 -1
  59. package/dist/egress/linuxBootstrap.js +47 -11
  60. package/dist/egress/linuxBootstrap.js.map +1 -1
  61. package/dist/egress/run.js +170 -31
  62. package/dist/egress/run.js.map +1 -1
  63. package/dist/errors/errorEngine.js +15 -3
  64. package/dist/errors/errorEngine.js.map +1 -1
  65. package/dist/errors/providerErrors.js.map +1 -1
  66. package/dist/evals/evals.js +304 -78
  67. package/dist/evals/evals.js.map +1 -1
  68. package/dist/evals/index.d.ts +2 -2
  69. package/dist/evals/index.js +1 -1
  70. package/dist/evals/index.js.map +1 -1
  71. package/dist/evidence/index.d.ts +2 -2
  72. package/dist/evidence/index.js +1 -1
  73. package/dist/evidence/index.js.map +1 -1
  74. package/dist/evidence/report.d.ts +1 -1
  75. package/dist/evidence/report.js +263 -79
  76. package/dist/evidence/report.js.map +1 -1
  77. package/dist/fault/faultLab.js +24 -9
  78. package/dist/fault/faultLab.js.map +1 -1
  79. package/dist/index.d.ts +42 -42
  80. package/dist/index.js +21 -21
  81. package/dist/index.js.map +1 -1
  82. package/dist/inventory/analysis.d.ts +1 -1
  83. package/dist/inventory/analysis.js +174 -50
  84. package/dist/inventory/analysis.js.map +1 -1
  85. package/dist/inventory/index.d.ts +4 -4
  86. package/dist/inventory/index.js +3 -3
  87. package/dist/inventory/index.js.map +1 -1
  88. package/dist/inventory/inventoryController.js +362 -115
  89. package/dist/inventory/inventoryController.js.map +1 -1
  90. package/dist/inventory/types.js +680 -140
  91. package/dist/inventory/types.js.map +1 -1
  92. package/dist/ledger/actionLedger.js +355 -78
  93. package/dist/ledger/actionLedger.js.map +1 -1
  94. package/dist/ledger/index.d.ts +2 -2
  95. package/dist/ledger/index.js +1 -1
  96. package/dist/ledger/index.js.map +1 -1
  97. package/dist/mcp/server.js +26 -11
  98. package/dist/mcp/server.js.map +1 -1
  99. package/dist/policy/index.d.ts +2 -2
  100. package/dist/policy/index.js +1 -1
  101. package/dist/policy/index.js.map +1 -1
  102. package/dist/policy/policy.js +112 -32
  103. package/dist/policy/policy.js.map +1 -1
  104. package/dist/productTelemetry/index.js +71 -20
  105. package/dist/productTelemetry/index.js.map +1 -1
  106. package/dist/providers/conformance.js +10 -5
  107. package/dist/providers/conformance.js.map +1 -1
  108. package/dist/providers/discord.js +2 -2
  109. package/dist/providers/generic.js +3 -3
  110. package/dist/providers/github.js +2 -2
  111. package/dist/providers/index.d.ts +3 -3
  112. package/dist/providers/index.js +2 -2
  113. package/dist/providers/index.js.map +1 -1
  114. package/dist/providers/openai.js +3 -3
  115. package/dist/providers/packs/resendPack.js +51 -25
  116. package/dist/providers/packs/resendPack.js.map +1 -1
  117. package/dist/providers/packs/stripePack.js +590 -121
  118. package/dist/providers/packs/stripePack.js.map +1 -1
  119. package/dist/providers/registry.js +4 -4
  120. package/dist/providers/registry.js.map +1 -1
  121. package/dist/providers/runtime.js +7 -6
  122. package/dist/providers/runtime.js.map +1 -1
  123. package/dist/providers/stripeWebhook.js +39 -10
  124. package/dist/providers/stripeWebhook.js.map +1 -1
  125. package/dist/providers/twilio.js +2 -2
  126. package/dist/proxy/cacheKey.js +9 -2
  127. package/dist/proxy/cacheKey.js.map +1 -1
  128. package/dist/proxy/providerDetector.js +22 -9
  129. package/dist/proxy/providerDetector.js.map +1 -1
  130. package/dist/proxy/proxyHandler.js +57 -22
  131. package/dist/proxy/proxyHandler.js.map +1 -1
  132. package/dist/proxy/requestNormalizer.js +4 -2
  133. package/dist/proxy/requestNormalizer.js.map +1 -1
  134. package/dist/reliability/costGovernance.js +211 -49
  135. package/dist/reliability/costGovernance.js.map +1 -1
  136. package/dist/reliability/index.d.ts +8 -8
  137. package/dist/reliability/index.js +4 -4
  138. package/dist/reliability/index.js.map +1 -1
  139. package/dist/reliability/reconciliation.js +274 -65
  140. package/dist/reliability/reconciliation.js.map +1 -1
  141. package/dist/reliability/runtimeHealth.js +127 -35
  142. package/dist/reliability/runtimeHealth.js.map +1 -1
  143. package/dist/reliability/slo.js +257 -50
  144. package/dist/reliability/slo.js.map +1 -1
  145. package/dist/report/safetyReport.d.ts +6 -0
  146. package/dist/report/safetyReport.js +56 -12
  147. package/dist/report/safetyReport.js.map +1 -1
  148. package/dist/rules/aiRules.js +5 -5
  149. package/dist/rules/aiRules.js.map +1 -1
  150. package/dist/safety/index.d.ts +2 -2
  151. package/dist/safety/index.js +1 -1
  152. package/dist/safety/index.js.map +1 -1
  153. package/dist/safety/safetyController.js +675 -165
  154. package/dist/safety/safetyController.js.map +1 -1
  155. package/dist/scenarios/scenarioBundle.js +204 -71
  156. package/dist/scenarios/scenarioBundle.js.map +1 -1
  157. package/dist/scenarios/scenarioStore.js +88 -29
  158. package/dist/scenarios/scenarioStore.js.map +1 -1
  159. package/dist/security/headerSanitizer.js +52 -10
  160. package/dist/security/headerSanitizer.js.map +1 -1
  161. package/dist/security/secrets.js +10 -5
  162. package/dist/security/secrets.js.map +1 -1
  163. package/dist/server/accessControl.js +37 -10
  164. package/dist/server/accessControl.js.map +1 -1
  165. package/dist/server/createServer.js +1 -1
  166. package/dist/server/createServer.js.map +1 -1
  167. package/dist/server/eventsStore.js +15 -5
  168. package/dist/server/eventsStore.js.map +1 -1
  169. package/dist/server/routes.js +67 -19
  170. package/dist/server/routes.js.map +1 -1
  171. package/dist/server/sse.js +1 -1
  172. package/dist/server/sse.js.map +1 -1
  173. package/dist/setup/sdkDetector.js +7 -2
  174. package/dist/setup/sdkDetector.js.map +1 -1
  175. package/dist/setup/setupGenerator.js +136 -48
  176. package/dist/setup/setupGenerator.js.map +1 -1
  177. package/dist/state/stateExtractor.js +3 -1
  178. package/dist/state/stateExtractor.js.map +1 -1
  179. package/dist/state/stateResolver.js +10 -7
  180. package/dist/state/stateResolver.js.map +1 -1
  181. package/dist/state/stateStore.js +13 -4
  182. package/dist/state/stateStore.js.map +1 -1
  183. package/dist/storage/fileStore.js +12 -4
  184. package/dist/storage/fileStore.js.map +1 -1
  185. package/dist/teamControl/controlPlane.js +846 -174
  186. package/dist/teamControl/controlPlane.js.map +1 -1
  187. package/dist/teamControl/deployment.js +19 -5
  188. package/dist/teamControl/deployment.js.map +1 -1
  189. package/dist/teamControl/index.d.ts +4 -4
  190. package/dist/teamControl/index.js +2 -2
  191. package/dist/teamControl/index.js.map +1 -1
  192. package/dist/tests/testGenerator.js +15 -7
  193. package/dist/tests/testGenerator.js.map +1 -1
  194. package/dist/trust/index.d.ts +2 -2
  195. package/dist/trust/index.js +1 -1
  196. package/dist/trust/index.js.map +1 -1
  197. package/dist/trust/trustLadder.js +309 -63
  198. package/dist/trust/trustLadder.js.map +1 -1
  199. package/dist/worlds/index.d.ts +2 -2
  200. package/dist/worlds/index.js +1 -1
  201. package/dist/worlds/index.js.map +1 -1
  202. package/dist/worlds/worlds.js +364 -65
  203. package/dist/worlds/worlds.js.map +1 -1
  204. package/docs/assets/dashboard.png +0 -0
  205. package/docs/assets/ghostapi-avatar.png +0 -0
  206. package/docs/ci.md +49 -49
  207. package/docs/github-actions.md +84 -84
  208. package/docs/mcp.md +58 -52
  209. package/docs/policy.md +63 -61
  210. package/docs/providers/authoring-packs.md +180 -175
  211. package/docs/providers/stripe-core-pack.md +84 -82
  212. package/docs/releases/README.md +13 -0
  213. package/docs/security/action-gateway-threat-model.md +34 -34
  214. package/docs/security/action-ledger-incident-replay-threat-model.md +42 -42
  215. package/docs/security/approval-inbox-threat-model.md +35 -35
  216. package/docs/security/credential-broker-threat-model.md +52 -52
  217. package/docs/security/egress-threat-model.md +126 -126
  218. package/docs/security/inventory-threat-model.md +104 -104
  219. package/docs/security/kill-switch-budgets-threat-model.md +37 -37
  220. package/docs/security/reliability-threat-model.md +111 -111
  221. package/docs/security/trust-ladder-threat-model.md +33 -33
  222. package/docs/telemetry.md +14 -0
  223. package/docs/usage.md +680 -571
  224. package/examples/README.md +10 -10
  225. package/examples/agent-instructions/README.md +39 -39
  226. package/examples/ci-smoke/README.md +21 -21
  227. package/examples/ci-smoke/ghostapi.policy.yaml +22 -22
  228. package/examples/ci-smoke/package.json +9 -9
  229. package/examples/ci-smoke/production-egress.mjs +4 -2
  230. package/examples/ci-smoke/safe.mjs +21 -17
  231. package/examples/evals/README.md +24 -24
  232. package/examples/evals/retry-after.eval.json +71 -52
  233. package/examples/generic-rest/README.md +27 -27
  234. package/examples/github-fetch/README.md +38 -35
  235. package/examples/openai-streaming/README.md +16 -16
  236. package/examples/openai-streaming/streaming-tool-call.mjs +44 -31
  237. package/examples/policy/ghostapi.policy.yaml +27 -27
  238. package/examples/record-replay/README.md +19 -19
  239. package/examples/record-replay/replay-requests.json +22 -22
  240. package/examples/record-replay/stripe-checkout.har.json +30 -30
  241. package/examples/resend-node/README.md +22 -22
  242. package/examples/stripe-node/README.md +35 -35
  243. package/examples/stripe-node/checkout-flow.mjs +87 -61
  244. package/examples/twilio-node/README.md +21 -21
  245. package/examples/worlds/README.md +19 -19
  246. package/examples/worlds/subscription-recovery.mjs +21 -12
  247. package/package.json +28 -6
  248. package/dist/landing/assets/index-BXR41fAD.css +0 -1
  249. package/dist/landing/assets/index-CxWsopzP.css +0 -1
  250. package/dist/landing/assets/index-D8_ggMRE.js +0 -55
  251. package/dist/landing/assets/index-DZlpyhqd.js +0 -55
  252. package/dist/landing/assets/index-Dk-Xezs3.js +0 -55
  253. package/dist/landing/index.html +0 -15
  254. package/dist/landing/landing.d.ts +0 -3
  255. package/dist/landing/landing.js +0 -12
  256. package/dist/landing/landing.js.map +0 -1
  257. package/docs/commercial/README.md +0 -29
  258. package/docs/commercial/data-inventory.md +0 -36
  259. package/docs/commercial/manual-invoicing.md +0 -44
  260. package/docs/commercial/metrics.md +0 -51
  261. package/docs/commercial/pricing.md +0 -103
  262. package/docs/commercial/privacy-policy-draft.md +0 -41
  263. package/docs/commercial/terms-topics-for-counsel.md +0 -51
  264. package/docs/design-partners/README.md +0 -52
  265. package/docs/design-partners/demo-narratives.md +0 -33
  266. package/docs/design-partners/design-partner-offer.md +0 -39
  267. package/docs/design-partners/discovery-questions.md +0 -28
  268. package/docs/design-partners/feedback-capture-template.md +0 -48
  269. package/docs/design-partners/icp-one-pager.md +0 -43
  270. package/docs/design-partners/onboarding-checklist.md +0 -33
  271. package/docs/design-partners/pilot-success-criteria.md +0 -27
  272. package/docs/design-partners/pricing-interview-script.md +0 -18
  273. package/docs/design-partners/telemetry-plan.md +0 -48
  274. package/docs/development/baseline.md +0 -114
  275. package/docs/development/onboarding-smoke.md +0 -37
  276. package/docs/development/verification-0.1.8.md +0 -25
  277. package/docs/enterprise-product-roadmap-ru.md +0 -1879
  278. package/docs/fundraising/README.md +0 -87
  279. package/docs/fundraising/data-room-checklist.md +0 -72
  280. package/docs/fundraising/demo-script.md +0 -52
  281. package/docs/fundraising/design-partners-50.md +0 -74
  282. package/docs/fundraising/launch-posts.md +0 -37
  283. package/docs/fundraising/metrics-and-evidence.md +0 -30
  284. package/docs/fundraising/roadmap-12-month.md +0 -25
  285. package/docs/fundraising/technical-due-diligence-index.md +0 -37
  286. package/docs/fundraising/yc-application.md +0 -25
  287. package/docs/hosted-pilot.md +0 -111
  288. package/docs/operations/disaster-recovery-runbook.md +0 -81
  289. package/docs/operations/kill-switch-runbook.md +0 -32
  290. package/docs/release-checklist.md +0 -83
  291. package/docs/release-migration-and-rollback.md +0 -63
  292. package/docs/release-readiness.md +0 -39
  293. package/docs/team-control-plane.md +0 -72
package/dist/landing/index.html DELETED
@@ -1,15 +0,0 @@
1
- <!doctype html>
2
- <html lang="en">
3
- <head>
4
- <meta charset="UTF-8" />
5
- <meta name="viewport" content="width=device-width, initial-scale=1.0" />
6
- <meta name="description" content="GhostAPI is the local internet for AI coding agents." />
7
- <title>GhostAPI - The local internet for AI coding agents</title>
8
- <link rel="icon" href="data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'%3E%3Crect width='100' height='100' rx='22' fill='%23121212'/%3E%3Cpath d='M26 36c0-12 10-22 24-22s24 10 24 22v36c0 7-8 10-13 5l-4-4-5 5-5-5-5 5-5-5-4 4c-5 5-13 2-13-5V36Z' fill='%233ecf8e'/%3E%3Ccircle cx='40' cy='42' r='5' fill='%23121212'/%3E%3Ccircle cx='60' cy='42' r='5' fill='%23121212'/%3E%3C/svg%3E" />
9
- <script type="module" crossorigin src="/landing/assets/index-DZlpyhqd.js"></script>
10
- <link rel="stylesheet" crossorigin href="/landing/assets/index-CxWsopzP.css">
11
- </head>
12
- <body>
13
- <div id="root"></div>
14
- </body>
15
- </html>
package/dist/landing/landing.d.ts DELETED
@@ -1,3 +0,0 @@
1
- import type { Request, Response } from "express";
2
- export declare const landingAssetsHandler: import("serve-static").RequestHandler<Response<any, Record<string, any>>>;
3
- export declare function landingHandler(_request: Request, response: Response): Promise<void>;
package/dist/landing/landing.js DELETED
@@ -1,12 +0,0 @@
1
- import express from "express";
2
- import { readFile } from "node:fs/promises";
3
- import { dirname, join } from "node:path";
4
- import { fileURLToPath } from "node:url";
5
- const __dirname = dirname(fileURLToPath(import.meta.url));
6
- export const landingAssetsHandler = express.static(join(__dirname, "assets"), { index: false });
7
- export async function landingHandler(_request, response) {
8
- response.setHeader("Content-Type", "text/html");
9
- const html = await readFile(join(__dirname, "index.html"), "utf8");
10
- response.status(200).send(html);
11
- }
12
- //# sourceMappingURL=landing.js.map
package/dist/landing/landing.js.map DELETED
@@ -1 +0,0 @@
1
- {"version":3,"file":"landing.js","sourceRoot":"","sources":["../../src/landing/landing.ts"],"names":[],"mappings":"AACA,OAAO,OAAO,MAAM,SAAS,CAAC;AAC9B,OAAO,EAAE,QAAQ,EAAE,MAAM,kBAAkB,CAAC;AAC5C,OAAO,EAAE,OAAO,EAAE,IAAI,EAAE,MAAM,WAAW,CAAC;AAC1C,OAAO,EAAE,aAAa,EAAE,MAAM,UAAU,CAAC;AAEzC,MAAM,SAAS,GAAG,OAAO,CAAC,aAAa,CAAC,MAAM,CAAC,IAAI,CAAC,GAAG,CAAC,CAAC,CAAC;AAE1D,MAAM,CAAC,MAAM,oBAAoB,GAAG,OAAO,CAAC,MAAM,CAAC,IAAI,CAAC,SAAS,EAAE,QAAQ,CAAC,EAAE,EAAE,KAAK,EAAE,KAAK,EAAE,CAAC,CAAC;AAEhG,MAAM,CAAC,KAAK,UAAU,cAAc,CAAC,QAAiB,EAAE,QAAkB;IACxE,QAAQ,CAAC,SAAS,CAAC,cAAc,EAAE,WAAW,CAAC,CAAC;IAChD,MAAM,IAAI,GAAG,MAAM,QAAQ,CAAC,IAAI,CAAC,SAAS,EAAE,YAAY,CAAC,EAAE,MAAM,CAAC,CAAC;IACnE,QAAQ,CAAC,MAAM,CAAC,GAAG,CAAC,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;AAClC,CAAC"}
package/docs/commercial/README.md DELETED
@@ -1,29 +0,0 @@
1
- # Commercial Readiness
2
-
3
- This directory prepares GhostAPI for evidence-led commercial conversations. It does not enable billing, subscriptions, entitlements, cloud telemetry, or a hosted service.
4
-
5
- ## Current Gate: Closed
6
-
7
- As of August 8, 2026, the repository has no dated, sanitized evidence of a paid pilot, LOI, weekly design-partner CI run, or confirmed customer outcome. The hosted service is an undeployed pilot skeleton. See the [design-partner validation kit](../design-partners/README.md).
8
-
9
- Do not add Stripe Billing, checkout, card collection, subscription state, server-side entitlements, or a paywall until the gate is met and a concrete paid workflow is selected. The OSS local runtime remains free and fully usable.
10
-
11
- ## Materials
12
-
13
- - [Pricing page copy and experiment](pricing.md)
14
- - [Manual pilot invoicing workflow](manual-invoicing.md)
15
- - [Commercial metrics plan](metrics.md)
16
- - [Privacy policy draft for counsel](privacy-policy-draft.md)
17
- - [Terms topics for counsel](terms-topics-for-counsel.md)
18
- - [Data inventory draft](data-inventory.md)
19
-
20
- ## Evidence Needed To Reopen The Gate
21
-
22
- Record a dated, sanitized primary source outside the public repository for at least one of these:
23
-
24
- - Three teams using GhostAPI weekly.
25
- - One design partner running GhostAPI in CI.
26
- - One confirmed bug caught before merge or production-egress attempt prevented by supported evidence.
27
- - One paid-pilot decision or specific LOI.
28
-
29
- Use the existing [pricing interview script](../design-partners/pricing-interview-script.md) and pilot criteria. A positive reaction, demo, or documentation change is not evidence of willingness to pay.
package/docs/commercial/data-inventory.md DELETED
@@ -1,36 +0,0 @@
1
- # Draft Data Inventory For Legal Review
2
-
3
- > **Draft only.** This inventory describes observed local-product behavior and proposed commercial categories as of August 8, 2026. It must be validated by engineering, operations, and qualified counsel before any hosted or paid service launches.
4
-
5
- ## Current Local Runtime
6
-
7
- | Data category | Purpose | Location | Default sharing | Retention boundary |
8
- | --- | --- | --- | --- | --- |
9
- | Local simulation state, scenarios, and contracts | Run deterministic local provider simulations and replays. | Operator-controlled `.ghostapi/` data directory. | None by GhostAPI. | Local files; documented bounded stores apply where implemented. |
10
- | Local events and evidence reports | Inspect local requests and generate sanitized CI evidence. | Operator-controlled `.ghostapi/` data directory. | None by GhostAPI. | Events/reports have documented local size/count retention. |
11
- | Local dashboard/MCP inputs | Display and control the operator's local runtime. | Process memory and operator-controlled local files where applicable. | None by GhostAPI. | Controlled by process lifetime and local retention behavior. |
12
- | Optional local telemetry aggregate | Measure local activation/recurrence only after explicit opt-in. | `.ghostapi/product-telemetry.json`. | No upload path. | Deleted by `ghostapi telemetry disable`; bounded while enabled. |
13
-
14
- The local tool can process data supplied by the operator, including values that may be sensitive. Secret masking and sanitization reduce exposure but are not a guarantee of complete redaction. Operators should not direct live production traffic or credentials to GhostAPI.
15
-
16
- ## Proposed Pilot And Commercial Records
17
-
18
- | Data category | Purpose | Proposed storage boundary | Prohibited content |
19
- | --- | --- | --- | --- |
20
- | Business contact and contracting details | Execute a signed pilot and communicate operationally. | Approved business/contract system, separate from product data. | Source code, traffic, credentials, payment-card data. |
21
- | Invoice/payment-status metadata | Issue and reconcile a fixed pilot invoice. | Approved accounting/invoicing system. | Card number, CVC, bank-login credentials, raw payment instrument data. |
22
- | Sanitized pilot outcome summary | Measure agreed success criteria and close out the pilot. | Access-controlled commercial record. | Raw evidence, logs, requests, prompts, end-user data, secrets. |
23
- | Opaque commercial metrics | Track counted outcomes and signed/collected pilot value. | Access-controlled private ledger. | Names, emails, repository/provider names, raw invoice data, telemetry identifiers. |
24
-
25
- ## Proposed Hosted Pilot Data
26
-
27
- The hosted architecture is not deployed. If it is launched after the design-partner gate is met, update this inventory with actual collection, schema, processor, deployment region, access controls, retention, backups, deletion/export mechanics, and incident-response evidence before onboarding a customer.
28
-
29
- The architecture currently proposes bounded sanitized CI report payloads, immutable scenario versions, organization/membership metadata, scoped ingest-key digests, idempotency records, job receipts, and audit metadata. It must not accept raw credentials, authorization headers, cookies, raw traffic, source code, or payment data.
30
-
31
- ## Access And Review
32
-
33
- - Local files are controlled by the operator's local filesystem permissions and data directory.
34
- - Commercial records require least-privilege finance/legal access and a documented retention review date.
35
- - Any future hosted roles, tenant isolation, backups, exports, and processors require implementation evidence and counsel review before claims are made.
36
- - Review this inventory after every new collection path, telemetry proposal, processor, billing system, provider integration, or retention change.
package/docs/commercial/manual-invoicing.md DELETED
@@ -1,44 +0,0 @@
1
- # Manual Paid-Pilot Invoicing Workflow
2
-
3
- ## Purpose And Boundary
4
-
5
- This is the only commercial collection path while GhostAPI's commercial gate is closed. It is a human-operated workflow for a signed, fixed-scope paid pilot. It does not create a checkout, subscription, payment portal, entitlement service, or card-data handling path.
6
-
7
- The OSS local runtime remains available regardless of invoice state. Do not disable, delete, or alter a partner's local data because a pilot expires, is cancelled, or has an overdue invoice.
8
-
9
- ## Preconditions
10
-
11
- Do not issue an invoice until all of the following exist:
12
-
13
- 1. A dated, sanitized evidence signal supports a paid-pilot discussion.
14
- 2. A written pilot proposal identifies the customer legal entity, scope, fixed fee, currency, tax treatment, payment terms, pilot dates, support boundary, success criteria, and cancellation/termination terms.
15
- 3. The legal and tax treatment has been reviewed for the seller and customer jurisdictions.
16
- 4. A customer billing contact and purchase-order requirements are confirmed through an approved business channel.
17
-
18
- ## Workflow
19
-
20
- 1. **Qualify:** Confirm the selected repository/workflow, buyer, measurable success criteria, and security boundary. Never request production credentials, raw traffic, source code, or personal data that is not needed for the commercial relationship.
21
- 2. **Approve proposal:** Obtain an executed order form, statement of work, or equivalent written acceptance before delivery beyond the agreed evaluation scope.
22
- 3. **Create invoice:** Use an approved accounting or invoicing system. Record only the business information required by that system and applicable law. Do not use GhostAPI local state, traffic logs, evidence artifacts, or source repositories as an invoicing system.
23
- 4. **Deliver payment instructions:** Send the invoice through the approved business channel. If the invoicing system offers card payment, the processor must host the payment collection page; GhostAPI must not receive card data.
24
- 5. **Record status:** In a private commercial ledger, store only an opaque pilot ID, invoice ID, amount/currency, issue/due/paid dates, status, and a link to the signed commercial record. Restrict access to authorized finance operators.
25
- 6. **Handle payment state:** Send a straightforward reminder after the stated due date. Pause only optional hosted or human support that the signed agreement explicitly makes conditional on payment. Preserve local OSS access and customer data.
26
- 7. **Close out:** Send the agreed evidence summary, record the buyer decision, and delete or retain commercial records only under the reviewed retention schedule.
27
-
28
- ## Cancellation And Failed Payment
29
-
30
- - Provide the cancellation contact and effective date in the written pilot terms. Do not use a dark pattern or require an impossible support path.
31
- - A disputed, failed, or overdue payment is a finance process, not a reason to erase evidence or local data.
32
- - Never retry a payment through GhostAPI. The accounting provider handles payment retry rules and payment data.
33
- - If a future hosted service is involved, establish a documented read/export and retention path before any access restriction. Do not promise automatic deletion or restoration without a tested implementation.
34
-
35
- ## Records And Privacy
36
-
37
- - Keep commercial records outside the public repository and separate from product telemetry.
38
- - Use an opaque pilot ID in metrics; do not include contact names, email addresses, repository names, provider names, source code, traffic, credentials, or raw evidence.
39
- - Do not put invoice numbers, addresses, banking details, tax identifiers, purchase orders, or payment links in `SESSION_LOG.md`, issue templates, product telemetry, or test fixtures.
40
- - The [data inventory draft](data-inventory.md) and [privacy policy draft](privacy-policy-draft.md) require legal review before any commercial use.
41
-
42
- ## Transition To Billing
43
-
44
- Move beyond this workflow only after the gate is met and the team has selected a billing provider, jurisdictional approach, entitlement contract, webhook/idempotency model, cancellation behavior, payment-failure policy, data-retention policy, and incident/reconciliation runbook. Implement and test those controls before accepting self-serve payment.
package/docs/commercial/metrics.md DELETED
@@ -1,51 +0,0 @@
1
- # Commercial Metrics Plan
2
-
3
- ## Boundary
4
-
5
- No new product telemetry is introduced by this plan. The implemented `ghostapi telemetry` feature remains local-only, disabled by default, aggregate-only, and has no upload path. See the [telemetry plan](../design-partners/telemetry-plan.md).
6
-
7
- This document defines a private, manual founder ledger for decision-making once a prospect or pilot explicitly shares a sanitized signal. It is not a customer analytics system.
8
-
9
- ## Metrics That Matter
10
-
11
- | Metric | Definition | Source | Privacy Rule |
12
- | --- | --- | --- | --- |
13
- | Weekly active teams | Teams with a consented, dated indication of meaningful local or CI use during a calendar week. | Sanitized partner confirmation or approved aggregate. | Store only opaque team ID, week, and source reference. |
14
- | Weekly protected CI workflows | Distinct selected workflows producing supported GhostAPI evidence in a week. | Sanitized partner-provided count. | No repository names, job names, payloads, or workflow logs. |
15
- | Confirmed outcomes | Bugs caught before merge or supported production-egress attempts prevented. | Sanitized closeout or evidence reference. | Store category/date/reference, never raw traffic or secrets. |
16
- | Paid-pilot decisions | Explicit `signed`, `declined`, `deferred`, or `OSS-only` decision. | Buyer decision record. | Store opaque account ID, date, and outcome. |
17
- | Booked pilot value | Contracted fixed pilot fees, excluding unapproved pipeline estimates. | Executed commercial record. | Store amount, currency, period, and opaque pilot ID only. |
18
- | Cash collected | Payments received for signed pilots. | Finance record. | Store invoice ID, amount/currency, date, and opaque pilot ID only. |
19
- | Pilot conversion | Signed paid pilots divided by proposals issued in a defined period. | Commercial ledger. | Count-only reporting. |
20
-
21
- ## Deliberately Excluded Metrics
22
-
23
- - Individual users, seats, source repositories, provider names, commands, traffic, code, prompts, agent content, credential data, customer end-user data, payment-card data, and raw invoice details.
24
- - Auto-collected funnel metrics, cross-device identifiers, session replay, behavioral profiling, and unconsented product analytics.
25
- - Pipeline dollar values presented as revenue, projected ROI, or unverified savings.
26
-
27
- ## Minimal Private Ledger Schema
28
-
29
- Maintain this outside the repository with least-privilege access:
30
-
31
- | Field | Rule |
32
- | --- | --- |
33
- | `account_id` | Random opaque identifier; never an email, company name, or repository name. |
34
- | `week_or_date` | ISO week or ISO date needed for the metric. |
35
- | `signal_type` | Allowlisted metric name from this document. |
36
- | `outcome` | Allowlisted value such as `signed`, `declined`, `deferred`, or `confirmed_bug_caught`. |
37
- | `amount` and `currency` | Present only for signed invoices or received payments. |
38
- | `source_reference` | Internal sanitized note or commercial-record reference, not raw content. |
39
- | `retention_review_date` | Date on which the record is reviewed under legal/privacy requirements. |
40
-
41
- ## Reporting Rules
42
-
43
- 1. Report counts and signed/collected amounts separately.
44
- 2. Label every metric as observed, target, or hypothesis.
45
- 3. Do not report a retention, conversion, or ROI figure without its denominator and a dated source period.
46
- 4. Do not treat an OSS download, demo, installation, or polite pricing response as a paying-customer signal.
47
- 5. Reconcile booked value and cash collected with the approved finance system before any board, investor, or public statement.
48
-
49
- ## Review Trigger
50
-
51
- Revisit the metric design only if a design partner explicitly requests hosted reporting or a validated paid workflow requires it. Any networked or account-level telemetry needs a new opt-in, schema, data-retention decision, threat model, and legal review.
package/docs/commercial/pricing.md DELETED
@@ -1,103 +0,0 @@
1
- # GhostAPI Pricing Page Copy And Experiment
2
-
3
- ## Status
4
-
5
- This is draft website copy for customer discovery. It is not a price list, offer, order form, or statement that a hosted service is available. GhostAPI has no self-serve billing, checkout, subscriptions, or card collection today.
6
-
7
- ## Page Copy
8
-
9
- ### Headline
10
-
11
- Keep local integration testing free. Pay only for proven team controls when the workflow is ready.
12
-
13
- ### Subheadline
14
-
15
- GhostAPI OSS Local remains a local-first MIT-licensed runtime for provider-shaped simulation, scenarios, MCP control, and safety evidence. Team and Enterprise are proposed paths for organizations that validate a recurring need for shared CI evidence and controlled workflows.
16
-
17
- ### OSS Local
18
-
19
- **Available now. Free and open source.**
20
-
21
- - Local runtime, CLI, MCP server, dashboard, local scenarios, provider packs, deterministic evals, and evidence generation.
22
- - No account, cloud connection, card, or artificial safety limitation.
23
- - Runs locally; Windows and macOS do not receive a claim of process egress enforcement equivalent to supported Linux namespace runs.
24
-
25
- ### Team
26
-
27
- **Design-partner proposal, not yet generally available.**
28
-
29
- For a team that has demonstrated recurring CI evidence or shared-scenario needs, a paid pilot may include a fixed, written scope for:
30
-
31
- - One or more protected repositories or CI workflows.
32
- - Shared scenario and policy review workflow.
33
- - Retained, sanitized CI evidence and closeout reporting.
34
- - Named pilot support and agreed success criteria.
35
-
36
- The current hosted implementation is an undeployed pilot architecture, not a generally available Team service. There is no self-serve signup, subscription, SLA, or entitlement claim.
37
-
38
- ### Enterprise
39
-
40
- **Discovery only. Not available for purchase.**
41
-
42
- Potential future scope may include enforced egress controls, identity and role controls, audit evidence, private deployment, retention requirements, and custom provider work. These capabilities require a validated workflow, a deployable control plane, security review, and written commercial terms before they can be offered.
43
-
44
- ### Call To Action
45
-
46
- If your team runs AI-assisted integration code in CI and needs proof that a selected workflow avoided production, request a design-partner conversation. Start with one repository, one risk, and one measurable outcome.
47
-
48
- ## FAQ Copy
49
-
50
- ### Is GhostAPI free?
51
-
52
- The OSS Local runtime is free and MIT licensed. It is not restricted to force an upgrade.
53
-
54
- ### Can I buy a Team plan today?
55
-
56
- No. Team is a proposed design-partner path, not a self-serve product. A paid pilot is considered only after a concrete workflow, buyer value, and written success criteria are validated.
57
-
58
- ### Do you charge by seats?
59
-
60
- Not currently. Seats are not the proposed primary value unit. The experiment tests value tied to protected workflows and retained evidence, not dashboard access.
61
-
62
- ### Which usage dimensions are being tested?
63
-
64
- Only dimensions linked to delivered value or a direct operating cost are candidates:
65
-
66
- | Candidate dimension | Why it maps to value | Current status |
67
- | --- | --- | --- |
68
- | Protected CI workflows or repositories | Defines the workflows receiving evidence and policy review. | Discovery only. |
69
- | Retained sanitized evidence | Maps to storage and audit/review utility. | Discovery only. |
70
- | Connected provider accounts | Relevant only if a future control plane manages distinct provider boundaries. | Discovery only. |
71
- | Production action executions | Relevant only after a safe production-action gateway exists. | Not implemented or offered. |
72
-
73
- There are no quotas, overages, usage meters, or feature gates today.
74
-
75
- ### Will GhostAPI process card data?
76
-
77
- No. Any future online billing provider must collect card data directly. GhostAPI must never receive, store, or log card numbers, CVCs, or payment credentials.
78
-
79
- ### What happens if a paid pilot ends or payment fails?
80
-
81
- The contractual workflow must preserve the partner's local OSS runtime and data. Any future hosted access change must be explicit, reversible where possible, and must not delete customer data because of non-payment.
82
-
83
- ## Pricing Experiment
84
-
85
- ### Hypothesis
86
-
87
- A buyer will fund a time-bounded pilot only when GhostAPI changes a real release, security, or integration decision through repeatable CI evidence. Local simulation alone is not assumed to justify payment.
88
-
89
- ### Unit To Test
90
-
91
- Offer one fixed-scope pilot, rather than a subscription. Scope is defined by protected workflow(s), agreed evidence retention, and success criteria. Do not quote a recurring price or usage rate before an interview establishes the buyer's value unit and procurement path.
92
-
93
- ### Interview And Quote Sequence
94
-
95
- 1. Use the [pricing interview script](../design-partners/pricing-interview-script.md) after a concrete workflow is understood.
96
- 2. Record a dated, sanitized answer in a private founder ledger: buyer role, value unit, budget signal, decision path, and result.
97
- 3. If the buyer requests a proposal, issue a written pilot scope with a fixed fee, start/end date, success criteria, support boundary, invoice schedule, and closeout decision.
98
- 4. Treat `no budget`, `OSS only`, and `needs evidence first` as valid outcomes. Do not convert interest into a false pricing signal.
99
- 5. Review at least three comparable signals before proposing a public Team price or adding billing software.
100
-
101
- ### Decision Rule
102
-
103
- Keep manual invoicing and do not build billing unless a signed paid pilot requires a repeatable paid service. Only then select a billing provider and design server-side entitlement checks around the validated paid workflow.
package/docs/commercial/privacy-policy-draft.md DELETED
@@ -1,41 +0,0 @@
1
- # Draft Privacy Policy For Legal Review
2
-
3
- > **Draft only. Not legal advice and not an operative privacy policy.** This document describes the current GhostAPI local-product behavior and proposed commercial boundaries as of August 8, 2026. Qualified counsel must review and replace it before any hosted service, paid pilot, public collection form, or commercial launch.
4
-
5
- ## Scope
6
-
7
- GhostAPI is an open-source local developer tool. The published local runtime does not require an account and does not send product traffic, source code, prompts, secrets, or telemetry to GhostAPI by default.
8
-
9
- The `hosted/` directory is an undeployed pilot architecture, not an operating service. This draft does not represent that a hosted service is currently collecting data.
10
-
11
- ## Current Local Processing
12
-
13
- The local runtime processes the API requests that an operator directs to `127.0.0.1` or another configured local bind address. It stores local simulation state, bounded events, scenarios, reports, and other files described in the project documentation. These files remain under the operator's configured local data directory unless the operator independently exports or shares them.
14
-
15
- The local runtime may mask secret-looking values before local logs, cache, dashboard, events, and prompts, but automatic sanitization is not a guarantee that every sensitive value is removed. Operators must review artifacts before sharing them.
16
-
17
- ## Optional Local Telemetry
18
-
19
- Product telemetry is disabled by default. If an operator runs `ghostapi telemetry enable`, the implementation records only a bounded local aggregate of four counters and activity weeks. It has no network transport, automatic upload, background process, account identifier, repository identifier, provider name, command capture, source code, traffic, prompt, credential, or personal-data field. `ghostapi telemetry disable` deletes that local aggregate.
20
-
21
- ## Proposed Commercial And Pilot Data
22
-
23
- Before a paid pilot, the parties should collect only the business information necessary for contracting, invoicing, support, and agreed pilot reporting. Possible categories include business contact details, contracting entity details, invoice and payment status metadata, and a customer-approved sanitized outcome summary.
24
-
25
- GhostAPI should not request or retain production credentials, payment-card data, raw provider traffic, source code, prompts, customer end-user data, or full evidence payloads for sales, invoicing, or metrics. Any approved accounting provider must collect payment-card information directly.
26
-
27
- ## Sharing
28
-
29
- The current local runtime has no GhostAPI-operated telemetry endpoint. A future commercial service must document each processor, purpose, legal basis, transfer location, retention term, and security measure before launch. It must not share data for advertising, sell personal information, or train external models on customer code, traffic, prompts, or secrets without separate, explicit authorization and a reviewed agreement.
30
-
31
- ## Retention And Deletion
32
-
33
- The local runtime follows its documented bounded local retention behavior. Commercial records and any future hosted data need jurisdiction-specific retention schedules, deletion/export processes, backup treatment, and legal-hold exceptions approved by counsel before collection. Do not promise a deletion period until those controls are implemented and verified.
34
-
35
- ## Rights And Contact
36
-
37
- Before an operative policy is published, establish a legal/privacy contact, request-verification process, response timelines, and region-specific disclosures. This repository intentionally does not invent a legal entity, address, contact email, or jurisdiction.
38
-
39
- ## Required Counsel Review
40
-
41
- Counsel should determine, at minimum: controller/processor roles, applicable privacy laws, lawful bases, notice/consent, data-processing agreements, cross-border transfers, subprocessors, security disclosures, retention, data-subject rights, children's data, marketing rules, breach notification, records of processing, and the relationship between the open-source license and any commercial terms.
package/docs/commercial/terms-topics-for-counsel.md DELETED
@@ -1,51 +0,0 @@
1
- # Terms Topics For Legal Review
2
-
3
- > **Discussion checklist only. Not terms of service, a contract, legal advice, or an offer.** Counsel must prepare and approve operative documents before GhostAPI accepts a paid pilot, processes personal data, or operates a hosted service.
4
-
5
- ## Product And License Boundary
6
-
7
- - Distinguish the MIT-licensed OSS Local runtime from any separately contracted pilot or hosted offering.
8
- - State that local use does not require a paid plan and that no OSS safety capability is artificially withheld for payment.
9
- - Define the pilot deliverables, support hours, implementation assistance, accepted use, documentation, and change-control process.
10
- - Avoid claims that GhostAPI provides complete host isolation, provider parity, compliance certification, or prevention of every production action.
11
-
12
- ## Commercial Terms
13
-
14
- - Legal entity names, authority to contract, order of precedence, pilot period, fixed fees, currency, taxes, invoice terms, purchase orders, late-payment handling, cancellation, suspension, refunds, and renewal/closeout decisions.
15
- - No payment-card collection by GhostAPI. A payment processor, if later selected, must handle card data directly.
16
- - The effect of non-payment must preserve local OSS access and must not destroy customer data.
17
- - State whether support is best-effort pilot support or subject to a separately negotiated SLA; do not imply an SLA without one.
18
-
19
- ## Data, Security, And Privacy
20
-
21
- - Data roles, data categories, permitted purposes, confidentiality, security measures, subprocessor process, data location, cross-border transfers, retention, export/deletion, backup/legal hold, incident notification, and audit rights.
22
- - Explicit prohibition on customer production credentials, raw traffic, source code, prompts, payment-card data, and personal data unless a future approved workflow and agreement require a narrowly defined exception.
23
- - Sanitization is defense in depth, not a guarantee; customers remain responsible for reviewing shared artifacts.
24
- - No AI-model training or external LLM disclosure using customer content without explicit, separate authorization.
25
-
26
- ## Intellectual Property
27
-
28
- - Ownership of the OSS project, pre-existing materials, customer materials, pilot deliverables, feedback, configurations, scenarios, evidence summaries, and improvements.
29
- - License grants needed to run a pilot, with limits on reverse engineering and redistribution only where legally appropriate.
30
- - Open-source notices and third-party dependency obligations.
31
-
32
- ## Risk Allocation
33
-
34
- - Warranties/disclaimers appropriate to an early pilot.
35
- - Limitation of liability, exclusion treatment, indemnities, insurance, force majeure, and survival clauses.
36
- - Security-incident and data-protection terms should align with actual technical controls, not aspirational architecture.
37
-
38
- ## Operational Terms
39
-
40
- - Named contacts, support channel, escalation path, maintenance windows if any, change notices, export format, termination assistance, and dispute/governing-law provisions.
41
- - No automatic renewal, cancellation obstacle, or subscription practice should be introduced without transparent written terms and counsel review.
42
-
43
- ## Documents To Prepare When The Gate Opens
44
-
45
- 1. Pilot order form or statement of work.
46
- 2. Master services agreement or equivalent terms.
47
- 3. Operative privacy notice.
48
- 4. Data-processing agreement, if applicable.
49
- 5. Security and subprocessor annex.
50
- 6. Invoice and tax process for the seller's jurisdiction.
51
- 7. Incident response and customer communication runbook.
package/docs/design-partners/README.md DELETED
@@ -1,52 +0,0 @@
1
- # Design-Partner Validation
2
-
3
- This directory is the working kit for validating whether GhostAPI solves an expensive enough problem before more cloud, enterprise, or billing scope is built.
4
-
5
- ## Evidence Status: August 8, 2026
6
-
7
- ### Facts
8
-
9
- - The local runtime, CI evidence model, deterministic evals, and team-control-plane prototype exist in this repository and have automated coverage.
10
- - `SESSION_LOG.md` records `0` CI design partners and `0` paying design partners as of August 4, 2026.
11
- - The repository contains no interview transcript, named customer record, weekly CI evidence, bug report from a user, LOI, paid pilot, or willingness-to-pay result.
12
- - Existing README text previously asserted that a design partner confirmed a workflow need, but this repository has no primary source that independently verifies that assertion. Treat it as an unverified prior note, not demand evidence.
13
-
14
- ### Hypotheses To Test
15
-
16
- - Teams using coding agents fear accidental production egress and lack proof that CI did not touch production.
17
- - Payment, webhook, and retry failures are painful enough that teams will add GhostAPI to merge-gating CI.
18
- - Platform, AppSec, and developer-productivity buyers value enforcement evidence more than another mock server.
19
- - A team that catches a real integration defect or blocks real egress will pay for enforced CI evidence and shared workflow controls.
20
-
21
- ### Targets, Not Results
22
-
23
- - Three teams use GhostAPI weekly.
24
- - One design partner runs GhostAPI in CI.
25
- - One user confirms a real bug was caught before merge or a production egress attempt was prevented.
26
- - One company agrees to a paid pilot or signs a specific LOI.
27
-
28
- ## Gate
29
-
30
- Do not expand cloud/enterprise scope based on this documentation alone. Continue the larger scope only after at least one target above is supported by a dated, sanitized source record. Store a summary, not source code, traffic, credentials, personal data, or raw interview recordings.
31
-
32
- ## Kit
33
-
34
- - [ICP one-pager](icp-one-pager.md)
35
- - [Discovery questions](discovery-questions.md)
36
- - [Design-partner offer](design-partner-offer.md)
37
- - [Pilot success criteria](pilot-success-criteria.md)
38
- - [Onboarding checklist](onboarding-checklist.md)
39
- - [Feedback capture template](feedback-capture-template.md)
40
- - [Pricing interview script](pricing-interview-script.md)
41
- - [Privacy-first telemetry plan](telemetry-plan.md)
42
- - [Demo narratives](demo-narratives.md)
43
-
44
- ## Evidence Ledger
45
-
46
- For every real conversation or pilot signal, add one sanitized row outside the public repository or in a private founder log:
47
-
48
- | Date | Team segment | Role | Signal | Evidence location | Next action |
49
- | --- | --- | --- | --- | --- | --- |
50
- | YYYY-MM-DD | e.g. B2B SaaS, 20-80 engineers | e.g. Platform lead | Interview / CI run / bug caught / LOI / paid pilot | Private sanitized note ID | Concrete follow-up |
51
-
52
- Do not fill this table with prospects, assumptions, or fabricated outcomes.
package/docs/design-partners/demo-narratives.md DELETED
@@ -1,33 +0,0 @@
1
- # Demo Narratives
2
-
3
- These are scripted demonstrations, not customer outcomes. Label them as demos until a user provides a dated, sanitized real-world record.
4
-
5
- ## 1. Prevented Production Egress
6
-
7
- **Buyer pain:** A coding agent can use a different HTTP client or shell command than the application's configured SDK and bypass a base-URL convention.
8
-
9
- **Story:** A developer runs an AI-generated integration test with `ghostapi run` on a supported Linux runner. The test tries to contact a non-loopback provider host. The namespace boundary denies external network routing while GhostAPI records only the permitted local interaction. The CI job publishes a sanitized evidence artifact and blocks merge because the requested external path cannot be safely proven.
10
-
11
- **Proof to show:** Linux preflight receipt, policy, sanitized evidence artifact, and failed CI status. Do not claim attribution of denied kernel socket attempts beyond the backend's documented capability.
12
-
13
- **Ask:** "Would an artifact showing the enforced boundary and the required scenario change how your team reviews agent-authored integration code?"
14
-
15
- ## 2. Duplicate Payment Bug Caught
16
-
17
- **Buyer pain:** A timeout after an ambiguous payment response can cause unsafe retry behavior and duplicate charges.
18
-
19
- **Story:** The demo uses GhostAPI's deterministic Stripe-shaped duplicate-payment eval. A deliberately unsafe sample retries a payment mutation without preserving idempotency. The evidence ties the repeated request sequence to the scenario; the eval fails before merge. The corrected implementation reuses the idempotency key and passes the ordered retry proof.
20
-
21
- **Proof to show:** The exact local scenario, evidence hash, failed eval, corrected eval, and no production credential.
22
-
23
- **Ask:** "Which of your real workflows has this kind of ambiguous-result or duplicate-side-effect risk?"
24
-
25
- ## 3. PR Blocked For Missing Webhook Signature Validation
26
-
27
- **Buyer pain:** A webhook handler may work in a happy-path test yet accept unsigned or incorrectly signed payloads.
28
-
29
- **Story:** A pull request adds a webhook endpoint but does not prove signature verification. The policy requires the webhook-signature eval. The CI report marks the requirement missing and returns a failing status. After the developer adds verification and the negative signed/invalid-signature test, the same required check passes.
30
-
31
- **Proof to show:** Required policy scenario, failing PR check, sanitized evidence showing the missing expectation, and passing artifact after the negative test.
32
-
33
- **Ask:** "Which security or integration checks do reviewers currently have to remember manually?"
package/docs/design-partners/design-partner-offer.md DELETED
@@ -1,39 +0,0 @@
1
- # Design-Partner Offer
2
-
3
- ## Offer
4
-
5
- GhostAPI will work with a small number of teams to prove one high-risk AI-assisted integration workflow before merge. The pilot focuses on a real buyer outcome: evidence that a chosen CI run did not reach production and that a specific failure path is exercised deterministically.
6
-
7
- ## What The Partner Contributes
8
-
9
- - One repository and one non-production integration workflow.
10
- - A technical owner who can run a local or Linux CI experiment weekly.
11
- - A buyer-side stakeholder for a 30-minute kickoff, weekly feedback, and a closeout decision.
12
- - Sanitized evidence of outcome only. No production credentials, raw traffic, proprietary code, or customer data are required.
13
-
14
- ## What GhostAPI Contributes
15
-
16
- - Local-first setup for the selected workflow.
17
- - A reviewed policy and deterministic scenario for one concrete risk.
18
- - A CI evidence artifact and a small closeout report based on observed runs.
19
- - Direct implementation support for agreed pilot blockers within the stated product boundary.
20
-
21
- ## Explicit Boundaries
22
-
23
- - GhostAPI is not a guarantee of complete host isolation, provider parity, or production compliance.
24
- - `ghostapi run` enforcement requires supported Linux namespace preflight; Windows and macOS do not receive an equivalent guarantee.
25
- - No automatic telemetry, cloud upload, raw traffic collection, or source-code transfer is part of the pilot.
26
- - The pilot does not authorize production actions or require production credentials.
27
-
28
- ## Suggested Timeline
29
-
30
- | Phase | Target | Evidence |
31
- | --- | --- | --- |
32
- | Kickoff | Week 0 | Selected repository, risk, owner, baseline workflow. |
33
- | First result | Week 1 | Local deterministic scenario and a reviewed evidence artifact. |
34
- | CI validation | Week 2 | Repeated CI runs or a documented blocker with owner/date. |
35
- | Closeout | Week 3-4 | Measured criteria, buyer decision, and willingness-to-pay interview. |
36
-
37
- ## Ask
38
-
39
- If the pilot proves a recurring release-risk reduction, agree to a paid-pilot discussion or a specific LOI decision at closeout. This is a request for a decision based on evidence, not a promise that the result already exists.
package/docs/design-partners/discovery-questions.md DELETED
@@ -1,28 +0,0 @@
1
- # Discovery Questions
2
-
3
- Ask for concrete recent behavior before presenting GhostAPI. Do not ask all questions mechanically; follow the evidence.
4
-
5
- 1. Tell me about the last integration change written or materially changed by a coding agent.
6
- 2. Which external provider made that change risky: money, messages, source control, AI spend, webhooks, or something else?
7
- 3. What happened when the team tested it?
8
- 4. Has a test, script, or agent ever hit the wrong environment? What was the impact?
9
- 5. How do you currently prevent production credentials from reaching agents or CI jobs?
10
- 6. How would a reviewer know that a pull request never contacted production?
11
- 7. Which failure modes have caused the most rework: retries, idempotency, rate limits, timeouts, malformed responses, or webhooks?
12
- 8. Describe the last duplicate side effect, such as a payment, message, ticket, or deployment. Where did detection fail?
13
- 9. How do you validate webhook signatures today? Is that test mandatory before merge?
14
- 10. What must happen in CI before an agent-authored integration change can merge?
15
- 11. Which repositories and runners could support a Linux CI experiment?
16
- 12. Which provider integration would make a pilot meaningful within two weeks?
17
- 13. What would be unsafe to store in a testing tool or evidence artifact?
18
- 14. What information would security require before allowing a developer tool to observe test execution?
19
- 15. Who owns the budget if this removes a recurring risk or release delay?
20
- 16. What would make this a must-have rather than a nice-to-have?
21
- 17. What existing tool or workaround would GhostAPI need to displace or complement?
22
- 18. What proof would make you trust a claim that production egress was blocked?
23
- 19. If the pilot catches nothing, what result would still show operational value?
24
- 20. If the pilot catches a real defect or blocks egress, what procurement or budget step could follow?
25
-
26
- ## Capture Rules
27
-
28
- Record direct quotes only with consent. Otherwise capture a sanitized summary, the workflow, severity, current workaround, decision owner, and next evidence-producing step. Never copy credentials, source code, raw traffic, customer data, or incident details into this repository.
package/docs/design-partners/feedback-capture-template.md DELETED
@@ -1,48 +0,0 @@
1
- # Feedback Capture Template
2
-
3
- Use this in a private founder system or a sanitized issue. Do not paste source code, traffic, credentials, tokens, personal data, or customer names unless independently authorized and stored in an approved system.
4
-
5
- ```markdown
6
- ## Validation Record
7
-
8
- - Date: YYYY-MM-DD
9
- - Record type: discovery | onboarding | CI run | bug caught | egress prevented | pricing | closeout
10
- - Company segment and engineering size:
11
- - Participant role:
12
- - Workflow / integration:
13
- - Coding-agent usage:
14
-
15
- ### Observed Facts
16
-
17
- - What actually ran or occurred:
18
- - Evidence location / sanitized reference:
19
- - Frequency / severity:
20
-
21
- ### User Interpretation
22
-
23
- - Why it matters to them:
24
- - Current workaround and cost:
25
- - Exact quote (only if consented):
26
-
27
- ### Product Hypothesis Tested
28
-
29
- - Hypothesis:
30
- - Supported / rejected / inconclusive:
31
- - Why:
32
-
33
- ### Commercial Signal
34
-
35
- - Buyer / decision process:
36
- - Budget or willingness-to-pay signal:
37
- - Paid pilot / LOI status:
38
-
39
- ### Next Step
40
-
41
- - Owner:
42
- - Due date:
43
- - Smallest evidence-producing action:
44
- ```
45
-
46
- ## Evidence Quality
47
-
48
- Prefer a dated CI artifact, issue/PR reference, or buyer confirmation over a feature request. Mark a signal `inconclusive` when it is based on a hypothetical answer, a demo reaction, or an unverified claim.