b2c-app-builder 0.221.39

package/catalog/workflows/operations-trust.ts

@@ -0,0 +1,425 @@
+import { workflow } from "./helpers.js";
+
+/**
+ * Ported from runtime/graph/workflows/operations-trust.ts. All are grantable-domain
+ * (domain.operations / domain.trust) and appear in catalog/bridge.ts's toCatalogInput().
+ *
+ * protectedCategory assignment follows the KTD4 rule verbatim: spend/release/destructive
+ * actionClass nodes get the matching protectedCategory automatically; credentials_access,
+ * legal_pricing, and public_actions tag a mutate/publish node only when its
+ * founderOnlyActions text actually names that resource (not every founder-gated node gets
+ * a protected-category tag — most are gated purely through the approvals mechanism).
+ */
+export const workflows = [
+  workflow({
+    id: "workflow.operations.paid-tool-routing-and-fallback",
+    founderPhrasings: [
+      "check if we already have access before paying for a tool",
+      "route around a tool that needs an account we don't have",
+      "find the free fallback instead of a paid service",
+    ],
+    title: "Paid-tool routing & fallback",
+    domainId: "domain.operations",
+    areaIds: ["area.business-operations-trust"],
+    trigger: "Before using or replacing any paid/account-gated tool, or before a free fallback",
+    instructions:
+      "At workflow start, walk the compiled start node plus its dependency closure — full-launch and complete-business walk `workflow.research.research-backed-spec` and its dependencies, including this node and `workflow.operations.live-app-store-portfolio` — and collect Tool Map names and MCP prefixes from instructions, consults, reads, and bound knowledge. Always add App Store Connect CLI and the live portfolio when that graph includes research-backed-spec or live-app-store-portfolio; a focused start lists only tools that graph actually names. Present one AskUserQuestion with multiSelect unset, a prompt body at or under 240 characters, and three options (recommended set, I'll pick next, defer optional) whose descriptions hold the names and jobs. Fold this into an already-pending readiness gate; do not open a second activeFounderGate. ASC and the live apps-list receipt stay required. I'll pick next records unnamed optionals as labeled fallback in the same turn. Deferred AppKittie, XPOZ, Firecrawl, or paid ASO continue as labeled fallback; deferred Higgsfield or MobAI upgrades mean no spend and no labeled-fallback generate. Tools named at intake get no second confirmation. Credit spend still uses a separate amount gate. Run ToolSearch for each tool's `mcp__<TOOLNAME>__` prefix before concluding it is unavailable. Record `Selected route:` in `strategy/TOOL_DECISIONS.md` plus per-tool rows with limitation text. Treat MobAI Free as needing no spend gate. Never present fallback output as equivalent to the paid-tool artifact.",
+    reads: ["state/business-state.json"],
+    consults: ["strategy/TOOL_DECISIONS.md"],
+    roleId: "role.operator-readiness",
+    laneIds: ["paid_tool_routing"],
+    phaseIds: ["phase.0b"],
+    outputPaths: ["strategy/TOOL_DECISIONS.md"],
+    gates: ["check:paid-tool-intake-required"],
+    providers: ["provider.doppler"],
+    founderOnlyActions: ["approve a paid or constrained fallback"],
+    actionClass: "mutate",
+    idempotent: true,
+  }),
+  workflow({
+    id: "workflow.operations.live-app-store-portfolio",
+    founderPhrasings: [
+      "list the apps already on this App Store account before we research",
+      "check live App Store Connect apps before we pick a product",
+      "do we already have an app on this Apple team",
+    ],
+    title: "Live App Store portfolio observe",
+    domainId: "domain.operations",
+    areaIds: ["area.business-operations-trust"],
+    trigger: "Before research-backed-spec on a complete-business or full-launch start; whenever Apple team or API auth changes",
+    instructions:
+      "Read the live App Store Connect portfolio with API auth only. Confirm `asc auth status --validate` on the winning binary, then run `asc apps list` and write `run/app-store-portfolio.json` with schema 1.0.0, command `asc apps list`, authFamily `api`, winnerVersion, observedAt, appCount, apps[] of sanitized `{name}` plus optional `{bundleId}`, and `empty: true` only when the live command returned no apps. Failed or missing API auth produces no receipt. A web session never satisfies this hold. Do not invent an empty portfolio. Do not store Apple numeric ids, SKU, raw stdout, session, or env. Compare names and bundle ids against `operations/business-access.json` `forbiddenProviderProjects[]` and refuse research that would target a match. A receipt older than seven days, or older than a later Apple-account checkedAt, is stale — re-run apps list. This node may remain held while reversible local prep continues; it blocks `workflow.research.research-backed-spec`.",
+    reads: ["operations/business-access.json"],
+    consults: ["operations/BUSINESS_ACCESS.md"],
+    roleId: "role.operator-readiness",
+    laneIds: ["store_console"],
+    phaseIds: ["phase.0-orient"],
+    outputPaths: ["run/app-store-portfolio.json"],
+    gates: ["check:app-store-portfolio-required"],
+    actionClass: "observe",
+    idempotent: true,
+  }),
+  workflow({
+    id: "workflow.operations.secrets-baseline-and-routing",
+    founderPhrasings: ["where does this new API key belong", "classify a credential before we store it anywhere", "keep secrets out of the wrong files"],
+    title: "Secrets baseline & routing",
+    domainId: "domain.operations",
+    areaIds: ["area.business-operations-trust"],
+    trigger: "Before any new secret, key, token, env var, webhook secret, or .env",
+    instructions:
+      "Before any new secret, API key, token, webhook signing secret, or `.env` value is introduced, classify it (public_client_config, server_secret, webhook_signing_secret, store_credential, oauth_or_refresh_token, ci_deploy_secret, runtime_user_secret, or local_operator_secret) and route it into Doppler by default — the business's own project for business-specific credentials, the shared `b2c` project for account-level ones — recording only the name, class, and location in `trust/secrets/SECRETS.md`, never the value. Resolve the Doppler config name from `SECRETS.md` or `doppler configs --project <name>` before constructing any `doppler run` command; never guess between naming conventions like `prod` and `prd`. Set automation-consumed secrets with `masked` (not `restricted`) visibility so `doppler run --` can inject them, and never `source` an `.env`/`.p8` file — extract single values with `awk -F= '/^KEY=/{print $2}' file`. `check:secrets` fails the lane if a raw secret value appears in git, docs, screenshots, or logs, or if production uses a personal CLI token instead of a service token or OIDC.",
+    reads: ["strategy/TOOL_DECISIONS.md", "state/business-state.json"],
+    consults: ["trust/secrets/SECRETS.md"],
+    roleId: "role.engineering-leader",
+    laneIds: ["secrets"],
+    phaseIds: ["phase.0c"],
+    outputPaths: ["trust/secrets/SECRETS.md"],
+    gates: ["check:secrets"],
+    providers: ["provider.doppler"],
+    founderOnlyActions: ["provide or authorize credentials"],
+    actionClass: "mutate",
+    protectedCategory: "credentials_access",
+    idempotent: true,
+  }),
+  workflow({
+    id: "workflow.trust.security-architecture-and-release-gate",
+    founderPhrasings: ["make sure this can't be hacked before we ship", "run a security review before launch", "check for vulnerabilities before we go live"],
+    title: "Security architecture & release gate",
+    domainId: "domain.trust",
+    areaIds: ["area.business-operations-trust"],
+    trigger: "Before threat modeling, hardening, scans, or any security-readiness claim. Founder phrasing: checked nobody can hack in or steal data.",
+    instructions:
+      "Create or refresh `trust/SECURITY.md` early enough (phase 1g) to shape `engineering/TECH_SPEC.md`, `trust/PRIVACY.md`, and `revenue/REVENUE_OPS.md`, then re-verify it as the release gate (phase 5c) before beta/TestFlight/store submission. Cover every required section — threat model, mobile hardening (Keychain/ATS/App Attest for iOS, Keystore/Network Security Config/Play Integrity for Android), backend/API controls, and revenue/entitlement abuse (RevenueCat/Stripe webhook signature verification, restore-purchases testing) — and mark platforms not in scope explicitly rather than omitting the section. Security is proven with evidence, not prose: attach scanner/review results or a founder-approved blocked route from `strategy/TOOL_DECISIONS.md` for each paid security tool (Claude Security, Codex Security, MobSF, Snyk/Semgrep) before claiming a section done. `npm run check:security` verifies the SECURITY.md contract shape, not vulnerabilities — pair it with an actual scan or review, and get founder sign-off on any accepted residual risk with an owner and revisit date.",
+    reads: ["engineering/TECH_SPEC.md", "strategy/TOOL_DECISIONS.md"],
+    // PRIVACY.md and REVENUE_OPS.md land at phase 3/3b, after this node's phase-1g threat-model
+    // firing — consults, so the early half is not held hostage to later lanes; the 5c release
+    // gate still cross-checks them via check:security once they exist.
+    consults: ["trust/SECURITY.md", "trust/PRIVACY.md", "revenue/REVENUE_OPS.md"],
+    roleId: "role.security-architect",
+    laneIds: ["security"],
+    phaseIds: ["phase.1g", "phase.5c"],
+    outputPaths: ["trust/SECURITY.md", "trust/security-review.html"],
+    gates: ["check:security"],
+    providers: ["provider.security-review", "provider.sentry"],
+    founderOnlyActions: ["accept residual security risk"],
+    actionClass: "mutate",
+    idempotent: true,
+  }),
+  workflow({
+    id: "workflow.trust.privacy-and-terms",
+    founderPhrasings: [
+      "write our privacy policy and terms of service",
+      "figure out what happens to user data legally",
+      "let people delete their account and their data",
+    ],
+    title: "Privacy & terms",
+    domainId: "domain.trust",
+    areaIds: ["area.business-operations-trust"],
+    trigger:
+      "Before privacy policy, terms, EULA, subscription terms, account-deletion, store disclosures. Founder phrasing: legal pages about data we collect, and agreeing to terms.",
+    instructions:
+      "Build the data inventory before drafting any policy text — trace actual data flows from `state/LAUNCH_TRACE.md` and `engineering/TECH_SPEC.md` (accounts, user content, device permissions, analytics/ads vendors, payments, AI processing) rather than starting from a template. Draft `trust/PRIVACY.md` and `trust/TERMS.md` to match actual practice — Apple's App Privacy answers and Google Play Data safety must match the same inventory — and publish stable `/privacy`, `/terms`, and `/delete-account` pages that return HTTP 200 and are linked from settings, App Store Connect, and Play Console. Clear the ten-risk checklist in `privacy-terms.md` §7 before calling this lane done: a findable data-collection disclosure, named third-party recipients, AI-processing disclosure when the product generates content, deletion that actually purges stored uploads, no public storage bucket, cancellation as easy as signup, and an auto-renewal reminder commitment. Produce `LEGAL_REVIEW.md` with sources checked, the data inventory table, store-disclosure mapping, and an explicit founder/counsel approval checkbox; never mark legal pages final without that approval. Verify contact-email MX records with `dig MX yourdomain.com +short` before writing any `@yourdomain.com` address into published copy — an unverified address that never receives mail is a store-policy and reputation risk. `npm run check:privacy` verifies the checklist's mechanical subset, not legal correctness.",
+    reads: ["state/LAUNCH_TRACE.md", "engineering/TECH_SPEC.md"],
+    roleId: "role.customer-success",
+    laneIds: ["privacy_legal"],
+    phaseIds: ["phase.3"],
+    dependencies: ["workflow.process.launch-trace-and-build-contracts"],
+    outputPaths: ["trust/PRIVACY.md", "trust/TERMS.md", "LEGAL_REVIEW.md"],
+    gates: ["check:privacy"],
+    founderOnlyActions: ["approve legal text"],
+    actionClass: "publish",
+    protectedCategory: "legal_pricing",
+    idempotent: true,
+  }),
+  workflow({
+    id: "workflow.operations.resend-email-ops",
+    founderPhrasings: [
+      "set up transactional emails for signup and receipts",
+      "get lifecycle emails actually landing in the inbox",
+      "configure the domain so our emails aren't marked as spam",
+    ],
+    title: "Resend email ops",
+    domainId: "domain.operations",
+    areaIds: ["area.business-operations-trust"],
+    trigger: "Before Resend domains/keys, transactional/lifecycle/broadcast email, deliverability",
+    instructions:
+      "Set up Resend with a purpose-specific sending subdomain (never the apex domain), add SPF/DKIM, then DMARC starting at `p=none` before tightening — verify all three pass on a real test send before any production email goes out. Classify every email as transactional, lifecycle, marketing/broadcast, or inbound/support; trigger lifecycle Automations from events that already exist in `analytics/ANALYTICS.md`, and adapt the starter pack at `growth/resend/email-templates.ts` with brand tokens pulled from `DESIGN.md` into `LaunchEmailBrand.designSystem` and tone from `11_STAR_EXPERIENCE.md` — do not ship generic-looking email. Verify webhooks against the raw request body and store processed `svix-id` values, since Resend webhooks are at-least-once and may duplicate. Every subject/preview/body must pass the `no-slop-writing.md` self-check in the product's brand voice, and `check:email` gates production sends on a verified domain, server-only API keys, and unsubscribe handling on every non-transactional message.",
+    reads: ["DESIGN.md", "analytics/ANALYTICS.md", "product/experience/11-star-experience/11_STAR_EXPERIENCE.md", "growth/resend/email-templates.ts"],
+    // customer-success over marketing-guru: the roster scopes "lifecycle copy" and the monitored
+    // inbox to customer success; the DNS/webhook setup half follows the runbook either way.
+    roleId: "role.customer-success",
+    laneIds: ["email"],
+    phaseIds: ["phase.4", "phase.6"],
+    dependencies: ["workflow.design.design-room", "workflow.data.analytics-and-attribution-blueprint"],
+    outputPaths: ["growth/EMAIL_OPS.md"],
+    gates: ["check:email"],
+    providers: ["provider.resend"],
+    actionClass: "publish",
+    // Production sends and DNS changes are public actions: the category is the authorization
+    // control (grants/waivers), independent of check:email's after-the-fact verification.
+    protectedCategory: "public_actions",
+    idempotent: false,
+  }),
+  workflow({
+    id: "workflow.operations.post-launch-operations",
+    founderPhrasings: [
+      "we're live, what's the weekly routine now",
+      "run the standard checklist now that this shipped",
+      "what should we be watching now that people are using this",
+    ],
+    title: "Post-launch operations",
+    domainId: "domain.operations",
+    areaIds: ["area.business-operations-trust"],
+    trigger: 'App live (phase_6/6b), "what now", weekly ops, incident response, retention reviews',
+    instructions:
+      "Run the named Weekly Ops Review in fixed order — metrics pull (PostHog/RevenueCat/console numbers, not adjectives), crash/review triage, support sweep, ASO delta, growth/spend review against `growth/PAID_UA.md`'s stop/scale rules, then ship one user-visible improvement — and log a one-line delta per step in `operations/POST_LAUNCH_OPS.md` dated against `lanes.post_launch_ops.live_since`. Before automating a value-producing loop, record one manual run with its input, output, result, cost, and failure mode; exempt necessary security, compliance, backup, and monitoring controls. Track discovery-to-owned-contact, owned-contact-to-activation, owned-contact-to-paid, and external-platform concentration when those metrics apply. Route involuntary billing churn through the recovery levers, not written off as normal, and when retention cohorts show a consistent drop at one step, open it through `change-cascade.md` rather than patching only the surface that failed. At the day-30 and day-90 checkpoints, prepare the Kill/Hold/Fix/Scale evidence pack (MRR trajectory, D7/D30 retention trend, CAC/LTV payback, founder hours) in `operations/LAUNCH_RETRO.md` — the agent assembles evidence, the founder makes the verdict. `check:post-launch` fails a checkpoint left uncompleted past its due date or a metric cell holding a placeholder instead of a number.",
+    // The three operating-lane artifacts are READS on purpose: recurrence reopens all four nodes
+    // each cycle, the lane nodes re-produce their artifacts first, and the changed inputs
+    // invalidate this review — so within one scheduled session the lanes run before the review
+    // that reads them, with no hand-authored ordering at all.
+    reads: ["state/business-state.json", "operations/SUPPORT_OPS.md", "operations/RETENTION_OPS.md", "operations/FINANCE_OPS.md"],
+    // PAID_UA.md's producer is the spend node, which parks until the founder funds it — a launch
+    // that never buys ads still runs post-launch operations, so this is a consult.
+    consults: ["operations/POST_LAUNCH_OPS.md", "operations/LAUNCH_RETRO.md", "growth/PAID_UA.md"],
+    roleId: "role.orchestrator",
+    laneIds: ["post_launch_ops"],
+    phaseIds: ["phase.6b"],
+    dependencies: ["workflow.engineering.engineering-orchestration-ce-production-readiness"],
+    outputPaths: ["operations/POST_LAUNCH_OPS.md", "operations/LAUNCH_RETRO.md"],
+    gates: ["check:post-launch"],
+    founderOnlyActions: ["decide Kill, Hold, Fix, or Scale"],
+    actionClass: "mutate",
+    idempotent: true,
+    // The Weekly Ops Review's own doctrine: the rhythm stops only on a recorded Kill verdict.
+    // This is the field that makes that true — the node reopens on its own calendar
+    // (reopenRecurringNodes) instead of `succeeded` being terminal.
+    recurrenceDays: 7,
+  }),
+  workflow({
+    id: "workflow.operations.support-queue-operations",
+    founderPhrasings: ["work through the customer support backlog", "clear out pending refund requests", "answer the tickets piling up in the inbox"],
+    title: "Support queue operations",
+    domainId: "domain.operations",
+    areaIds: ["area.business-operations-trust"],
+    trigger: "App live: the recurring support sweep; an inbox, review queue, or refund/restore request needing a worked answer",
+    instructions:
+      'Work the support queue to zero or to documented escalations every cycle, and prove it in `operations/SUPPORT_OPS.md`: a dated row per sweep with queue depth, oldest-ticket age, and what shipped or escalated — counted state, never "inbox fine". State the response SLA once and honor it (`check:post-launch` fails a runbook with no SLA or a queue row older than two weeks). Route refund/restore and privacy/delete requests through the store-automatic flows first; anything beyond them — goodwill refunds, comped time — is a founder-only gate per knowledge §12. Public replies under the business identity follow the founder-approved pattern; the first occurrences and the standing tone are the founder\'s call, after which routine replies within that pattern proceed. Feed recurring ticket themes into the Weekly Ops Review as improvement candidates — a support queue that never changes the product is a complaint archive.',
+    reads: ["state/business-state.json"],
+    consults: ["operations/POST_LAUNCH_OPS.md"],
+    roleId: "role.customer-success",
+    laneIds: ["post_launch_ops"],
+    phaseIds: ["phase.6b"],
+    dependencies: ["workflow.engineering.engineering-orchestration-ce-production-readiness"],
+    outputPaths: ["operations/SUPPORT_OPS.md"],
+    gates: ["check:post-launch"],
+    providers: ["provider.resend"],
+    founderOnlyActions: ["approve the first public replies and the standing reply tone under the business identity"],
+    actionClass: "mutate",
+    idempotent: true,
+    recurrenceDays: 7,
+  }),
+  workflow({
+    id: "workflow.operations.retention-intervention",
+    founderPhrasings: [
+      "people are canceling, figure out what to do about it",
+      "respond to a drop in retention this cycle",
+      "people are churning, what's the plan",
+    ],
+    title: "Retention intervention",
+    domainId: "domain.operations",
+    areaIds: ["area.business-operations-trust"],
+    trigger: "App live: the recurring retention pass; a cohort drop, involuntary-churn spike, or cancellation trend needing a worked response",
+    instructions:
+      "Read the cohorts every cycle and do something about them, and prove both in `operations/RETENTION_OPS.md`: name the cohort source once (PostHog cohorts plus RevenueCat renewals — `check:post-launch` fails a program with no named source), record a dated row with the measured D7/D30 values (percentages, or the dated blocker that stopped the pull), and keep an Intervention section logging what was tried, when, and what moved. Route involuntary billing churn through the recovery levers in `billing-health-and-reactivation.md` — failed payments written off as normal churn is the named anti-pattern. When a cohort shows a consistent drop at one step, open it through `change-cascade.md` rather than patching only the surface that failed. Interventions that change pricing or public messaging are founder-only; everything else ships within the standing autonomy grants and reports in the row it shipped in.",
+    reads: ["state/business-state.json"],
+    consults: ["operations/POST_LAUNCH_OPS.md"],
+    roleId: "role.customer-success",
+    laneIds: ["post_launch_ops"],
+    phaseIds: ["phase.6b"],
+    dependencies: ["workflow.engineering.engineering-orchestration-ce-production-readiness"],
+    outputPaths: ["operations/RETENTION_OPS.md"],
+    gates: ["check:post-launch"],
+    founderOnlyActions: ["approve retention interventions that change pricing or public messaging"],
+    actionClass: "mutate",
+    idempotent: true,
+    recurrenceDays: 7,
+  }),
+  workflow({
+    id: "workflow.operations.financial-health-review",
+    founderPhrasings: [
+      "check how the business is doing financially this cycle",
+      "review revenue and burn for this cycle",
+      "are we actually profitable right now",
+    ],
+    title: "Financial health review",
+    domainId: "domain.operations",
+    areaIds: ["area.business-operations-trust"],
+    trigger: "App live: the recurring financial pulse; a spend change, refund spike, or runway question",
+    instructions:
+      'Read the money every cycle and prove it in `operations/FINANCE_OPS.md`: a dated row with the MRR-labeled dollar amount from RevenueCat ("MRR $0" is a legitimate value; an adjective is not), monthly spend across tools and acquisition, and the runway or burn those two imply (`check:post-launch` fails a pulse with no MRR figure or no runway statement). Reconcile against the pricing scenarios and stop/scale rules the strategy docs carry — spend drifting past its stop rule surfaces here first, before the weekly review decides anything. This node assembles the evidence; verdicts stay where they belong: kill/hold/fix/scale is the Weekly Ops Review\'s founder gate, and spend changes route through the paid-acquisition gates.',
+    reads: ["state/business-state.json"],
+    consults: ["operations/POST_LAUNCH_OPS.md", "growth/PAID_UA.md"],
+    roleId: "role.orchestrator",
+    laneIds: ["post_launch_ops"],
+    phaseIds: ["phase.6b"],
+    dependencies: ["workflow.engineering.engineering-orchestration-ce-production-readiness"],
+    outputPaths: ["operations/FINANCE_OPS.md"],
+    gates: ["check:post-launch"],
+    providers: ["provider.revenuecat"],
+    actionClass: "observe",
+    idempotent: true,
+    recurrenceDays: 7,
+  }),
+  workflow({
+    id: "workflow.operations.scheduled-autonomy-installation",
+    founderPhrasings: [
+      "set up a schedule so this runs on its own",
+      "install a recurring job without me starting it by hand",
+      "automate the operating rhythm going forward",
+    ],
+    title: "Scheduled autonomy installation",
+    domainId: "domain.operations",
+    areaIds: ["area.business-operations-trust"],
+    trigger: "Business live and the founder wants the operating rhythm to run without anyone starting sessions by hand; changing or removing that schedule",
+    instructions:
+      "Install the OS-level trigger that keeps the operating loop alive: run `adapters/install-schedule.ts` in its default dry-run first and show the founder the exact crontab line (or launchd plist) it would install — mechanism, cadence, runtime, wrapper path, and log path — then run it with `--apply --approval workflow.operations.scheduled-autonomy-installation.approval.1` only after the current scheduled-autonomy founder approval is approved, because a standing schedule on their machine is their call, every time. Verify the installation with the command the dry-run prints (`crontab -l | grep b2c:<slug>` or `launchctl list`), and record the whole arrangement in `operations/SCHEDULE.md`: mechanism, cadence, runtime, brief path, wall-clock cap, the verify command, the exact uninstall command (`--uninstall --apply --approval workflow.operations.scheduled-autonomy-installation.approval.1`), and the note that the kill switch in `control/control.json` stops every scheduled session cold even while the OS keeps firing the trigger. The scheduled session itself reopens recurring work (the weekly ops review, the growth iteration loop) on its own calendar — this node installs the heartbeat, it does not do the week's work.",
+    reads: ["state/business-state.json"],
+    consults: ["operations/POST_LAUNCH_OPS.md"],
+    roleId: "role.orchestrator",
+    laneIds: ["post_launch_ops"],
+    phaseIds: ["phase.6b"],
+    outputPaths: ["operations/SCHEDULE.md"],
+    founderOnlyActions: ["approve installing, changing, or removing the recurring session schedule on this machine"],
+    actionClass: "mutate",
+    idempotent: true,
+    applicability: {
+      mode: "conditional",
+      question: "Is recurring scheduled operation selected for the current business?",
+    },
+  }),
+  workflow({
+    id: "workflow.operations.founder-zero-operator-bootstrap",
+    founderPhrasings: [
+      "set up my accounts and recovery options before we go further",
+      "decide how much autonomy the agent should have",
+      "get the business identity and two-factor recovery squared away",
+    ],
+    title: "Founder-zero operator bootstrap",
+    domainId: "domain.operations",
+    areaIds: ["area.business-operations-trust"],
+    trigger:
+      "After an accepted product enters the durable runtime; required before authenticated providers, standing authority, spend, public actions, or releases",
+    instructions:
+      "When the durable runtime starts, offer one optional step-away setup. Settle autonomy and budget, confirm business identity and founder-owned recovery/2FA, inventory only the accounts required by accepted near-term work, and record exact external authority in operations/business-access.json. If this gate is already pending, fold the start-of-workflow recommended tool set into the same AskUserQuestion rather than opening a second tool gate. This setup may remain held while reversible local prep, product definition drafts, design drafts, local implementation, and local tests continue. It does not authorize dispatch of `workflow.research.research-backed-spec`; that node stays frontier-blocked until `workflow.operations.live-app-store-portfolio` succeeds. Complete the setup before authenticated provider work, standing schedules, spend, public actions, testing-track uploads, or releases. Keep one structured `activeFounderGate`, set it to `null` while work can continue, and combine missing tools or roles into one handoff. Never request secrets in chat. Consume matching standing envelopes without asking twice. Pause only for missing or expired scope, ceiling overruns, protected identity, legal, pricing, or credential changes, destruction, or an unapproved public release.",
+    reads: ["state/business-state.json"],
+    consults: ["operations/BUSINESS_ACCESS.md", "operations/business-access.json"],
+    roleId: "role.operator-readiness",
+    outputPaths: ["operations/BUSINESS_ACCESS.md", "operations/business-access.json"],
+    gates: ["check:founder-operator"],
+    founderOnlyActions: ["approve the consolidated step-away authority and complete unavoidable ownership authentication"],
+    actionClass: "mutate",
+    protectedCategory: "credentials_access",
+    idempotent: true,
+  }),
+  workflow({
+    id: "workflow.operations.agent-operations-ledger",
+    founderPhrasings: [
+      "log what accounts and access this action needs before doing it",
+      "check what's required before touching a provider account",
+      "record which credentials this task will use",
+    ],
+    title: "Agent operations ledger",
+    domainId: "domain.operations",
+    areaIds: ["area.business-operations-trust"],
+    trigger: "Before any authenticated browser/API/CLI/native action on a provider, social, or store account",
+    instructions:
+      "Before authenticated provider work starts, derive the required capability list from accepted scope and inspect only the applicable connectors, APIs/CLIs, accounts, environments, signing, deployment, store, analytics, revenue, email, and support routes. Record exact accounts, projects/apps, modes, checked times, and durable operator roles in `operations/agent-operations.json`. Create separate standing envelopes for website deployment, asset work, approved store metadata/media, and testing-track uploads. Classify each external action and bind it to a matching current envelope. Consume a current envelope without asking twice. Use the narrowest route, capture sanitized before-state, act, read back provider state, and reconcile proof. Combine missing capabilities or authority into one handoff while local work continues. Identity, legal, pricing, credential-role, destructive, and unapproved public-release changes remain exceptional gates. Run `npm run check:agent-operations` before an unattended-readiness or authenticated-operation claim.",
+    reads: ["state/business-state.json"],
+    consults: ["operations/AGENT_OPERATIONS.md", "operations/agent-operations.json", "operations/PROVIDER_PROOF.md"],
+    roleId: "role.operator-readiness",
+    dependencies: [
+      "workflow.operations.founder-zero-operator-bootstrap",
+      "workflow.operations.paid-tool-routing-and-fallback",
+      "workflow.operations.secrets-baseline-and-routing",
+    ],
+    outputPaths: ["operations/AGENT_OPERATIONS.md", "operations/agent-operations.json"],
+    gates: ["check:agent-operations"],
+    providers: [
+      "provider.doppler",
+      "provider.app-store-connect",
+      "provider.google-play",
+      "provider.posthog",
+      "provider.revenuecat",
+      "provider.stripe",
+      "provider.resend",
+      "provider.app-store-screenshots",
+      "provider.higgsfield",
+      "provider.mobai",
+      "provider.in-app-ios-simulator",
+      "provider.codex-native-ios",
+      "provider.snapshot-previews",
+      "provider.serve-sim",
+      "provider.aso-skills",
+      "provider.refero",
+      "provider.security-review",
+      "provider.sentry",
+      "provider.paid-ad-channels",
+    ],
+    actionClass: "mutate",
+    idempotent: true,
+  }),
+  workflow({
+    id: "workflow.trust.community-and-user-safety",
+    founderPhrasings: [
+      "handle someone being abusive to other users",
+      "moderate content people post inside the app",
+      "decide how to report and block bad actors",
+    ],
+    title: "Community and user safety",
+    domainId: "domain.trust",
+    areaIds: ["area.business-operations-trust"],
+    trigger: "When the product includes social, chat, creator, or other user-generated content",
+    instructions:
+      "Confirm whether users can create, share, discover, or message content. When required, define moderation, reporting, blocking, escalation, support contact, age controls, response targets, and evidence. Record the operating model in trust/COMMUNITY_SAFETY.md. Test the common abuse and recovery paths. Do not mark this work as not needed without a reason and product evidence.",
+    reads: ["PRODUCT.md", "trust/PRIVACY.md"],
+    roleId: "role.security-architect",
+    laneIds: ["security", "privacy_legal"],
+    phaseIds: ["phase.3", "phase.5c"],
+    dependencies: ["workflow.research.research-backed-spec"],
+    outputPaths: ["trust/COMMUNITY_SAFETY.md"],
+    actionClass: "mutate",
+    idempotent: true,
+    applicability: {
+      mode: "conditional",
+      question: "Does the product include social, chat, creator, or other user-generated content?",
+    },
+  }),
+  workflow({
+    id: "workflow.trust.generative-ai-safety",
+    founderPhrasings: [
+      "make sure the AI doesn't generate something harmful",
+      "put guardrails on AI-generated content",
+      "decide what the AI is not allowed to produce",
+    ],
+    title: "Generative-AI safety",
+    domainId: "domain.trust",
+    areaIds: ["area.business-operations-trust"],
+    trigger: "When the product generates text, images, audio, or video",
+    instructions:
+      "Confirm whether the product generates text, images, audio, or video. When required, define prohibited uses, input and output controls, reporting, enforcement, human escalation, age controls, and model or provider responsibilities. Test harmful, deceptive, exploitative, and sexual-content abuse cases. Define a named self-harm and crisis response — detect self-harm/suicide/crisis language and respond with a real crisis resource, not a generic refusal — and test that path explicitly; it is not covered by the general harmful-content test. Record controls and evidence in trust/AI_SAFETY.md. When a capability can create paid model-provider spend, write trust/AI_PROVIDER_CONTROLS.md with auth, entitlement, reservation, kill switch, one backend secret, and separate application versus provider-account cap status. If paid generation does not apply, still write that file with Paid generation: not applicable and a named reason. Do not mark this work as not needed without a reason and product evidence.",
+    reads: ["PRODUCT.md", "trust/SECURITY.md", "trust/PRIVACY.md"],
+    roleId: "role.security-architect",
+    laneIds: ["security", "privacy_legal"],
+    phaseIds: ["phase.3", "phase.5c"],
+    dependencies: ["workflow.research.research-backed-spec"],
+    outputPaths: ["trust/AI_SAFETY.md", "trust/AI_PROVIDER_CONTROLS.md"],
+    gates: ["check:ai-provider-controls"],
+    extensionSlots: ["cost-boundary"],
+    actionClass: "mutate",
+    idempotent: true,
+    applicability: {
+      mode: "conditional",
+      question: "Does the product generate text, images, audio, or video?",
+    },
+  }),
+] as const;