stripe-history

Imported from hraness/stripe-history (AGENTS.md). Install upstream with npx skills add hraness/stripe-history. Copyright stays with the author.

Contents

• app/ – the public timeline, category, annual-volume, valuation, data, and methodology pages, plus crawl metadata, social image, and framework shell.
• lib/ – strict history and research YAML contracts with validated content loading.
• public/history/ – the authored, source-linked Stripe history records.
• public/research/ – the canonical source catalog, valuations, founder appearances, collection definitions, research-run ledger, and bounded automatic-publication policy and attestations.
• scripts/ – bounded discovery and publication, Stripe Sessions extraction, research audit and planning, and structured-output helpers.
• assets/ – the Hraness README lockup.
• .agents/skills/ – reusable cross-repository KB and phased-execution workflows.
• kb/ – authored repository rationale, evidence, synthesis, and plans.
• WRITING.md and STYLE.md – internal and public prose contracts.
• .github/workflows/ – standalone repository validation.
• README.md, CONTRIBUTING.md, SECURITY.md, CITATION.cff, and LICENSE – project documentation, citation metadata, policy, and terms.
• package.json, tsconfig.json, eslint.config.mjs, and bun.lock – the standalone Next.js application and verification configuration.

Guidelines

• Use Bun 1.3.14 for installs, scripts, and checks.
• Follow WRITING.md for internal prose and STYLE.md for public prose.
• Apply unreasonably robust programming when agent work is cheap. Model invalid states out of existence, parse provider and authored data from unknown, and pair readable regression examples with property tests for general laws.
• Deliver completed task-owned changes by fast-forward push to main after repository checks, including schemas, public contracts, generated files, lockfiles, and provider configuration. If main advances, replay the task-owned commits on the new head and rerun the affected checks. Use a pull request only when the user explicitly asks for one or an external contributor cannot push directly. Never force-push.
• Pin Hraness dependencies to reviewed immutable releases or full commits. Never connect repositories with sibling paths, Git submodules, or coordinated main assumptions.
• Use immutable @hraness/web-discovery exports for generic metadata and JSON-LD serialization, and @hraness/vercel-delivery for the generic Vercel proof and Preview response contract. Keep history semantics, research schemas, redirects, crawl policy, and editorial presentation product-owned.
• Extract a shared package only after two concrete consumers need the same stable interface. Keep shared packages product-neutral.
• Use a shared design kit or @hraness/ui only for stable, portable primitives and tokens at an immutable version. Keep evidence modeling, timeline composition, methodology, and the local visual contract product-owned.
• Keep Nebula Sans from the immutable design-kit release as the ordinary proportional face across the timeline shell, assets, and social images. Preserve the explicit monospace heading and data roles.
• Freeze shared interfaces before parallel lanes begin. Give authored-corpus migrations, manifests, lockfiles, and other convergence surfaces one owner while lanes edit disjoint paths.
• Keep mandatory rules in the closest AGENTS.md, current procedures in docs/, executable contracts in types and tests, and pull-based rationale, evidence, synthesis, and plans in kb/.
• Keep the canonical public identity at https://hraness.com/stripe. Deploy the application with the /stripe base path behind Hraness, and preserve former hosts only as direct permanent redirects to the matching canonical path.
• Treat Production as the only durable Vercel environment. Pull requests may use Vercel's built-in disposable Preview target, but do not create a custom environment, persistent Preview domain, provider-authoritative Preview branch, or separate Preview backend.
• Keep stripe-history/* as the stable public schema and prompt-version namespace. Identity changes do not rewrite published data contracts or append-only attestations.
• Keep history server-rendered, crawlable, and available as reviewable YAML. Preserve durable category, annual-volume, valuation, and data URLs.
• Give every ordinary themed page exactly one shared icon-menu appearance control as the final action in its header. Do not put appearance controls in footers, content, or fallback action rows.
• Require at least one canonical source ID for every event and valuation observation. Prefer primary evidence, preserve uncertainty, and distinguish proposed, reported, announced, and completed events.
• Parse every provider response and YAML file from unknown. Preserve reverse chronology, globally unique IDs, bounded text, and deterministic source provenance.
• Keep the site independent of Stripe, Inc. Do not imply endorsement, ownership, or official status.
• Keep the Hraness Ra lockup linked to https://hraness.com/ in the website footer and README.
• Treat this repository as the complete project. Use only its public names, paths, commands, and dependencies.
• Run bun run check before handing off a change.

• Treat the user's request to change this repository as standing authorization for routine task-owned commits, pushes, pull requests, merges, releases, deployments, and production verification after the gates applicable to that action pass. Do not ask for duplicate confirmation. Build confidence through relevant automated checks, bounded diagnostics, and independent review, not another human approval. Passing checks does not expand task scope or authority.
• Prefer agentic service provisioning for new infrastructure. Check Vercel Marketplace for a native product that can provision the required resource first; use Stripe Projects as a supported alternative when it better covers the service or the Marketplace route only connects an existing account. Verify the current catalog, account, region, plan, recurring cost and resource capabilities before selecting a route. Prefer supported provider CLIs or APIs over browser-only setup when neither catalog fits, and explain the concrete exception. Reuse existing owner-controlled resources where appropriate; this preference alone does not authorize migrations, duplicate accounts, paid upgrades or wider access. Continue setup already authorized by the task and budget without duplicate confirmation. Keep provider credentials and generated environment files private, complete required interactive authentication, and verify deployment, persistence and recovery separately from successful provisioning.
• Separate artifact admission from live qualification and operational activation. Use applicable automated source, security, package/install, and provenance evidence for artifact admission; live provider qualification is not a universal publication prerequisite. Preserve explicit live acceptance criteria and require relevant live evidence for claims that depend on it. If publication or an artifact's install, upgrade, or default-use path activates risky unqualified behavior, keep that behavior guarded or disabled, or obtain bounded relevant evidence before shipping or activation.
• Use the repository's documented delivery workflow and preserve the identity, target, capacity, migration, and recovery guards applicable to operational activation. Replace an obsolete gate through a reviewed source and policy change with corresponding tests, never an ad hoc skip. Preserve every runtime-enforced approval, access control, branch protection, environment rule, safety policy, and required final gate. Ask for user input only when delivery needs a material product decision, missing credentials or authority, unavoidable interactive authentication, an irreversibly destructive action outside task scope, or resolution of a failure that cannot be handled safely and autonomously.
• Preserve production and user data throughout delivery. Inspect the exact account, environment, deployment, and data target before writes. For data changes, inspect a dry run or equivalent migration plan and validate the recovery path before any effect that could lose or corrupt data. Prefer additive, backward-compatible migrations and bounded batches. Record mutation intent, use idempotency or conditional writes, and reconcile uncertain results before retrying. Verify deployed identity, health, and relevant data invariants after delivery. Routine delivery never authorizes resetting, truncating, dropping, or overwriting user data; stop the unsafe operation if preservation or recovery cannot be established.
• Prefer short-lived repository workload identities such as OIDC trusted publishing, GitHub Apps, and narrowly scoped machine identities. Use unattended stable publication and production promotion when supported by the provider and repository. Establish supported machine authority once and verify it with a non-publishing preflight where available; routine releases should not require recurring interactive authentication or conversational approval. Retain account two-factor authentication and provider controls, including required authentication for approval of an exact staged artifact; do not add long-lived personal tokens to eliminate an interactive prompt.
• Keep delivery gates proportional to the failure they prevent. Prefer required checks on the current integration candidate, independent agent review, and atomic or conditional integration. Add a merge queue or another approval stage only for a demonstrated coordination or safety need. Replace redundant queues, serial waits, and duplicate checks through reviewed policy changes while retaining evidence for the integrated result.
• Preserve useful reasoning fan-out, but avoid unnecessary checkout fan-out. Prefer subagents in the current task for bounded research, review, diagnosis, and focused checks when they can safely share one working tree; create a separate task or worktree only for independently deliverable divergent edits, an isolated verification tree, or a different execution environment.
• Give each expensive focused validation command and external wait one owner. The integration owner reviews that evidence and runs the repository-required aggregate or final gate once after convergence. Reuse evidence only for the exact Git tree, command, lockfiles, toolchain, relevant environment, and validity period, and never to skip a required final integration, merge, release, deployment, or production-verification gate.
• On Hraness development machines, use $oompa-local-efficiency and the installed host scheduler for heavyweight top-level commands when available. Keep ordinary work in the compute lane; give authenticated browser/dev-server/Chromium work one browser-auth owner and Mac-only validation one mac-native owner.
• When a CI or policy gate scans complete Git history, check out the exact governed SHA and fetch only the fully qualified governed refs before scanning. Preserve the complete-history gate and reject unexpected refs instead of importing unrelated concurrent heads.
• At closeout, record applicable branch, PR, check, merge, release, deployment, and production evidence. Archive only conclusively finished tasks, never from silence alone, and reclaim only freshly revalidated clean merged worktrees through the guarded exact-path flow.

• costs.json at the repository root is the checked registry of every product data surface: store, kind (authoritative | derived | telemetry | served), retention class (ephemeral | ttl:<ISO-8601> | account | tombstone | persistent), owner module, and budget. A new table, bucket, stream, dynamic route, blob, or provider meter fails check:cost-surfaces until it registers.
• Bound every input before storage or provider I/O: request bytes, row counts, page sizes, batch sizes, retry counts, and event payloads. Unbounded input is a contract violation.
• No writes on read paths. Reads may cache; they never mutate.
• Derived state is rebuildable and lives in the cheapest tier that can serve it. Only authoritative state pays for transactional storage.
• Every mutation carries an idempotency key; a retried write never double-charges storage, quota, or provider spend.
• Analytics and metering events come from a checked allowlist with a byte ceiling per event.
• Content bytes live in the content store; the control plane keeps references and metadata only.
• Run bun run check:cost-surfaces before handoff whenever a data surface changes.

ALGAL skills

• Prefer the globally installed algal-* skills for bounded git state, diffs, repository survey/search, test and release gates, CI polling, and web fetches instead of repeated raw tool output.
• At session start, if the algal skill is unavailable, install the current skill pack for Claude Code, Codex, and Devin for Terminal with bunx skills add 0thernet/algal-skills --global --agent claude-code codex devin --skill '*' --copy --yes.
• Confirm installation with bunx skills list --global. If Bun or network access is unavailable, continue with repository-native tools instead of blocking delivery.
• Treat ALGAL receipts as execution evidence, not provider attestation, and preserve the repository's normal verification and release gates.