b2c-app-builder 0.221.39

package/knowledge/operations/autonomy-onboarding.md

@@ -0,0 +1,269 @@
+# Autonomy Onboarding
+
+Use this at the very start of a business's first session — interactive or scheduled, since both are
+sessions and both act — and again whenever the founder wants to change how much they've handed over
+in one area. Waiting for the first _unattended_ run is too late: a founder who says "launch me a
+business" and watches it happen is not watching every step of it, and an agent that never held this
+conversation is one deciding its own permissions.
+
+It reuses the conversation shape in [`founder-zero-operator.md`](./founder-zero-operator.md) (phase and
+outcome first, plain definitions, two or three choices with the recommendation first, consequences
+spelled out, a safe way to skip or come back later) applied to two specific decisions: how much this
+agent should be allowed to do on its own, area by area, and how much it may spend doing it.
+
+Nothing here is settled by silence. The first session offers one recommended operator-ready setup.
+This setup lets the founder step away after the agent verifies access, tools, limits, and targets.
+
+## Contents
+
+- The Promise
+- The Three Ways To Set Up Each Area
+- The Nine Areas Of The Business
+- The Step-Away Readiness Check
+- Protected Moves And Your Okay
+- How Much It May Spend
+- The Fast Path
+- After The Conversation
+
+## The Promise
+
+Open with something like:
+
+> I can prepare this business so you can step away. I will check the accounts, roles, tools,
+> deployment targets, store access, signing access, and spending limit now. I will then build,
+> create assets, deploy the approved website, and upload approved store material without asking
+> again. You can change or revoke this access later.
+
+## The Three Ways To Set Up Each Area
+
+Every area of the business gets one of three settings. Explain these once, before going area by
+area:
+
+- **Ask me first.** The safest setting. I'll research, draft, and prepare things in this area, but
+  I stop and check with you before anything actually happens. Nothing moves without your yes.
+- **Handle the routine stuff.** I do the everyday work in this area myself and tell you what I did
+  afterward. I still stop and ask before anything unusual, risky, or outside the ordinary pattern
+  for this area.
+- **Full trust.** I run this area on my own judgment, start to finish. I use standing approvals for
+  named accounts and routine public work. I stop only when the work exceeds a recorded limit or
+  changes a protected item. See "Protected Moves And Your Okay" below.
+
+If the founder isn't sure about an area, the safe move is to skip it: nothing in that area happens
+on its own until they decide, and it comes back up later rather than staying an open question
+forever.
+
+## The Nine Areas Of The Business
+
+Walk through these one at a time, or all at once if the founder takes the fast path below. For
+each area: say what it covers in one sentence, give the recommended setting first, then the other
+two options, then the skip route.
+
+### Product
+
+What you're building: the market research behind it, the product itself, how it feels to use, and
+every word inside it.
+
+- **Recommended: handle the routine stuff.** I'll keep researching, refining, and writing here on
+  my own, and check with you before anything unusual.
+- Ask me first, if you'd rather see everything before it's final.
+- Full trust, if you want me making the calls here without checking in.
+- Not sure? Skip it for now — I'll keep this area on the safest setting until you decide.
+
+### Design
+
+Look and feel: brand, visuals, motion, and the on-screen craft.
+
+- **Recommended: handle the routine stuff.** I'll keep the visual system moving on my own and flag
+  anything that's a real style decision rather than routine polish.
+- Ask me first, if you want to review the look before it ships.
+- Full trust, if you're comfortable with me making style calls independently.
+- Not sure? Skip it for now.
+
+### Engineering
+
+Building the app: the code, the architecture, and getting it running on real devices.
+
+- **Recommended: handle the routine stuff.** I'll write and ship ordinary code changes myself and
+  flag anything structural or unusual.
+- Ask me first, if you want to see changes before they land.
+- Full trust, if you want me building independently.
+- Not sure? Skip it for now.
+
+### Growth
+
+Marketing and growth: getting people to find and try the app.
+
+- **Recommended: handle the routine stuff.** I'll run ordinary growth work — content, outreach,
+  everyday campaign upkeep — on my own and flag anything that's a real strategy change.
+- Ask me first, if you want to approve growth moves before they go out.
+- Full trust, if you want me driving growth independently.
+- Not sure? Skip it for now.
+
+### Analytics
+
+Analytics and tracking: knowing what's working and what isn't.
+
+- **Recommended: handle the routine stuff.** I'll keep tracking and reporting on my own and flag
+  anything that looks off.
+- Ask me first, if you want to review findings before I act on them.
+- Full trust, if you want me acting on what the numbers say without checking in.
+- Not sure? Skip it for now.
+
+### Revenue
+
+Pricing and getting paid: subscriptions, purchases, and the money side.
+
+- **Recommended: handle the routine stuff.** I keep products, entitlements, approved offers, and
+  billing operations current. I do not choose a new price, trial, or payment account.
+- Handle the routine stuff, if you want me managing the everyday money work myself and only
+  flagging anything unusual.
+- Full trust, if you want me running this independently. Spending beyond what's routine is always
+  a protected move either way — see below.
+- Not sure? Skip it for now — this stays on the safest setting until you decide.
+
+### Store
+
+App Store and Google Play: the listing, screenshots, and the submission itself.
+
+- **Recommended: full trust.** I create and update listings, screenshots, previews, product pages,
+  release notes, and review information. I upload builds to TestFlight and internal or closed Play
+  tracks when the standing approval names the app, account, and track. I do not publish a final
+  production release unless that exact release is also approved.
+- Handle the routine stuff, if you're comfortable with me keeping the listing current on my own.
+- Full trust, if you want me managing this independently.
+- Not sure? Skip it for now.
+
+### Trust
+
+Privacy, security, and legal: keeping the app, and your users' data, safe and compliant.
+
+- **Recommended: handle the routine stuff.** I keep security, privacy inventories, disclosures,
+  and compliance evidence current. New legal promises and final legal text stay protected.
+- Handle the routine stuff, if you want me keeping this current on my own and flagging anything
+  that changes what the app promises.
+- Full trust, if you want me running this independently. Changing a price or a legal term stays a
+  protected move either way — see below.
+- Not sure? Skip it for now — this stays on the safest setting until you decide.
+
+### Operations
+
+Running the business day to day: accounts, tools, and the operating work behind the scenes.
+
+- **Recommended: handle the routine stuff.** I'll keep the operating work moving on my own and
+  flag anything unusual.
+- Ask me first, if you want to review this work before it happens.
+- Full trust, if you want me running this independently.
+- Not sure? Skip it for now.
+
+## The Step-Away Readiness Check
+
+Run this once before build work starts. Ask one combined question, not one question per provider.
+Offer the operator-ready choice first. Then inspect and verify each item yourself.
+
+The check covers:
+
+- autonomy grants for all nine business areas
+- a spending amount, currency, period, and stop condition
+- founder-owned business email, recovery, 2FA, and revocation paths
+- Doppler or the approved secret manager and a durable operator identity
+- source control, CI, hosting, DNS, and the exact website project and environment
+- image, video, copy, screenshot, device, simulator, and localization tools
+- Apple Developer, App Store Connect, signing, TestFlight, and upload roles
+- Google Play Console, service-account access, app signing, and testing-track roles
+- analytics, revenue, email, support, and social accounts that are in scope
+- standing approval envelopes for the routine operations below
+
+The agent records the matching protected authorization and separate standing approvals behind this
+conversation. Each approval names the provider, account, project or app, environment, exact work
+and resources, exclusions, expiry, and rollback route. It cannot use a broad wildcard. Prepare
+approvals for:
+
+1. Deploy the approved landing site to the named preview and production project.
+2. Generate and revise marketing, landing, store, and lifecycle assets inside the spending limit.
+3. Apply approved website copy, onboarding, metadata, screenshots, previews, and product pages.
+4. Upload signed builds to TestFlight and approved Play testing tracks.
+5. Update approved prices only when the exact price table has separate pricing approval.
+
+Do not ask again when a current capability and standing envelope match the action. Record the
+action, read back the result, and continue. If several permissions or tools are missing, combine
+them into one founder handoff. Continue all work that does not depend on those missing items.
+
+The founder can choose an assisted setup instead. In that mode, use ask-me-first settings and
+prepare drafts without publishing. A skipped answer grants nothing.
+
+## Protected Moves And Your Okay
+
+Even at full trust, seven kinds of moves need a current standing or one-shot approval. `docs/authority-envelopes.md` names what actually enforces each one. Read it before treating any of these as fully covered by a standing envelope:
+
+- Spending money beyond the routine, already-approved amount
+- Connecting a new account or changing a credential role
+- Changing a price or a legal term
+- Publishing outside the approved site, store, or copy scope
+- Any post in the founder's public voice — a social post, a launch announcement. This always needs a fresh, per-item decision. It never runs on a standing envelope, no matter how exactly it matches an approved scope
+- Submitting or releasing an app outside an exact, version-pinned release envelope
+- Deleting or otherwise permanently changing something
+
+If the founder wants to pre-approve one of these, collect all of the following before recording
+it — a pre-approval with any of these missing does not take effect:
+
+1. **Exactly what this covers.** Name the provider, account, project, environment, allowed
+   operations, resources, and exclusions.
+2. **A cap, and how often it resets.** A maximum for one action, a maximum for a stretch of time,
+   and whether that stretch is a day, a week, a month, or a single work session.
+3. **When this pre-approval runs out.** A firm date. It does not renew itself — when it passes,
+   the founder is asked again.
+4. **What happens if it goes wrong.** Either a real way to undo it ("I can reverse this by doing
+   X"), or, for the handful of moves that truly can't be undone — submitting to a store, deleting
+   something for good — a plain acknowledgment that it can't be undone, plus the exact steps that
+   limit the damage if it does go wrong.
+
+Never record a vague or open-ended pre-approval. One onboarding answer can create several separate
+envelopes. Each envelope must cover only one protected category and one clear operation family.
+
+## How Much It May Spend
+
+The settings above answer whether the agent may act. They do not answer how much it may commit, and
+those are different questions — a business with all nine areas granted and no money answer still
+cannot pay for a web address. Ask this once, in the same conversation:
+
+> Separately from what I'm allowed to do: how much is this business willing to spend, and over what
+> stretch of time? I'll work inside that and stop when it's used up, instead of asking you to
+> approve every small thing. If you'd rather not set anything aside yet, that's a fine answer — I'll
+> bring you each spending decision as it comes.
+
+For each area that gets money, collect three things: **which area** it belongs to, **an amount and a
+currency**, and **how often it resets** — a day, a week, or a month. The founder can approve a
+repeating budget during onboarding. The agent stops at the ceiling and reports actual spending.
+It does not infer a higher limit.
+
+Setting nothing aside is a real answer and the default. It blocks nothing that costs nothing; it
+means spending waits for the founder each time instead of running inside an agreed limit.
+
+Keep this separate from a pre-approval above. An approval envelope says which operations are
+allowed. A budget says how much the area may use. Collect both during step-away setup so routine
+spending does not create repeated questions.
+
+## The Fast Path
+
+Offer this first:
+
+> I can set up step-away mode now. I will use full trust for product, design, engineering, growth,
+> store, and operations. I will use routine authority for analytics, revenue, and trust. I will
+> verify every required account and tool, and create separate standing approvals for website
+> deployment, asset creation, store material, and test-build uploads. I will stop only for missing
+> access, a budget overrun, a new price or legal promise, an identity change, deletion, a social or
+> public-voice post, or a final public release that you did not approve here. Do you want this
+> recommended setup?
+
+If they say yes, collect the spending limit and release choice in the same exchange. The release
+choice is either test uploads only or one exact production release. Do not add later confirmation
+steps for operations already covered by the resulting standing envelopes.
+
+## After The Conversation
+
+Once the founder has answered, put their choices into effect right away — there's no separate
+"activate" step. Tell them plainly what just changed and where they can see and change it later:
+their autonomy console shows every area's current setting, any pre-approvals in effect and when
+they expire, money committed and remaining, and anything currently waiting on their decision.
+Changing an answer later means having this same conversation again for just the one area they
+want to revisit — nothing about the rest is disturbed.

package/knowledge/operations/doppler-organization.md

@@ -0,0 +1,73 @@
+# Doppler organization across a portfolio
+
+Load when setting up secrets for a new business, adding a second business to an
+existing account, or deciding where a newly required credential belongs.
+
+## The rule
+
+**One project per business. One shared `b2c` project for everything account-level.
+Repos map to configs, never to projects.**
+
+A credential belongs in `b2c` when one account serves every business (a
+Resend account hosting many sending domains, one Anthropic key, one App Store
+Connect key, one Cloudflare token). It belongs in the business project when it is
+that business's own (its Supabase keys, its RevenueCat app key, its PostHog
+project key, its store identifiers).
+
+## Why not a project per repo
+
+A business with web + Flutter + backend repos does not want three projects. Web
+and Flutter share the same client-safe values (Supabase URL, anon key, analytics
+project key); splitting by repo duplicates them and they drift. And per-repo
+projects still do not stop a server secret being pasted into the mobile one.
+
+The boundary that matters is not _which repo_ — it is **can this token read a
+server secret**. Configs express that directly:
+
+| Config       | Holds                                           | Consumed by                 |
+| ------------ | ----------------------------------------------- | --------------------------- |
+| `prd` (root) | client-safe + business-shared                   | web, mobile                 |
+| `prd_server` | adds service-role keys, webhook signing secrets | backend, scheduled sessions |
+| `prd_ci`     | adds deploy and store credentials               | CI                          |
+
+A branch config inherits its environment's root config, so `prd_server` sees
+everything in `prd` plus its own. A token scoped to `prd` cannot see the branch
+extras. That inheritance is core Doppler behavior, available on every plan.
+
+## Composing the shared account tier
+
+Cross-project inheritance (`doppler configs update --inherits`) is a paid-tier
+feature. Do not depend on it. Compose at the consumer instead — this works on
+every plan and keeps the precedence rule in code we can test:
+
+```bash
+doppler run -p <account> -c <config> -- doppler run -p <business> -c <config> -- <command>
+```
+
+The inner injection wins, so a business may override a shared account-tier value. The
+provisioning resolver applies the same precedence when it checks which
+requirements are satisfied.
+
+## Naming and binding
+
+Projects are named for the business slug (`clueless-clothing`, `shade-diary`).
+Configs are `dev` / `stg` / `prd` plus the `prd_server` / `prd_ci` branches.
+Conventions drift in real accounts, so the workspace control file records the
+project and config this business actually binds to — a business whose project
+predates the convention keeps working without a rename.
+
+Bind the workspace directory once so ordinary commands need no flags:
+
+```bash
+doppler setup --project <business> --config prd_server --no-interactive
+```
+
+## Constraints worth knowing before you plan
+
+- **Inheritance and tokens are per workplace.** A single shared `b2c` project can
+  only serve businesses in the same workplace. Businesses split across two
+  workplaces cannot share it; consolidate before building the shared tier.
+- **Service tokens are per config.** Automation gets a read-only service token
+  scoped to one config, never a personal login token.
+- **Creating projects and tokens is an account mutation** — a founder-gated
+  action. Propose the exact commands; let the founder run or approve them.

package/knowledge/operations/founder-zero-operator.md

@@ -0,0 +1,184 @@
+# Founder-Zero Business Operator
+
+## Support And Recovery Ownership
+
+Assign a durable owner for support, provider recovery, store-account recovery, billing disputes, security incidents, and data-export requests. Confirm that recovery email, phone, two-factor authentication, and backup-code custody belong to the business. Never store recovery secrets in the workspace. Test the escalation route and record sanitized proof before unattended operation.
+
+Use this at the beginning of every broad launch or business-operations task. Assume the founder knows the product idea and desired outcome but may know nothing about accounts, providers, social platforms, domains, analytics, stores, security, or launch sequencing. The agent is the operating lead: explain plainly, choose the next useful step, execute everything it safely can, and pause only for the smallest founder-only action.
+
+## Contents
+
+- Founder-Zero Promise
+- Conversation Protocol
+- Business Bootstrap Sequence
+- Doppler And Login Model
+- Social Account Access
+- Authorization Boundaries
+- Proof And Continuity
+- Failure Conditions
+
+## Founder-Zero Promise
+
+- Never assume the founder knows a platform name, role model, credential type, command, or next step.
+- Never dump the full launch checklist on the founder. Keep the complete plan in durable artifacts and present one next founder action plus what the agent will do immediately afterward.
+- Explain each request in plain language: why it matters, what screen or decision is involved, what the founder should expect, and what the agent will verify.
+- Do not turn the founder into the project manager. The agent owns sequencing, research, setup, drafts, implementation, testing, reconciliation, and follow-through.
+- Treat "I do not know" as the default, not a blocker. Inspect the repo, browser, current tool catalog, official docs, and provider state before asking.
+- Prefer doing the work through current connectors, APIs, CLIs, authenticated browser control, and native tools. A manual packet is the final fallback.
+
+The default opening should be equivalent to:
+
+> I will prepare the business so you can step away. I will ask once for the authority, accounts, roles, and spending limit that the work needs. I will then build, create assets, deploy the approved website, and upload store material without repeated approvals. You keep ownership, recovery, 2FA, legal identity, and any final release that you do not approve up front.
+
+## Conversation Protocol
+
+Prefer one opening readiness question. Use this question contract when a real exception remains:
+
+1. **Phase and outcome:** say which launch phase is active, what the agent is doing, and what this decision unlocks.
+2. **What and why:** explain the gate in one sentence each; define any unfamiliar role, research, provider, or business term before using it.
+3. **One selectable question:** use AskUserQuestion when available, or the same plain-text prompt otherwise. Offer two or three mutually exclusive choices, put the recommended choice first, and do not require free-text reconstruction when a selection works. The prompt body stays at or under 240 characters. If a start-of-workflow tool intake is due and a readiness gate is already pending, fold the recommended tool set into that same question; do not open a second `activeFounderGate`.
+4. **Consequences:** for every choice state what happens, what the agent does next, and how readiness/evidence changes.
+5. **Skip, fallback, or defer:** make the safe route explicit and say when the gate returns. Access, money, legal, pricing, public voice, release, and destructive gates can be deferred while safe preparation continues, but never bypassed.
+6. **Lifecycle:** no answer means `pending`, never consent. Move resolved, stale, or superseded gates to `gateHistory`. If a new direct founder instruction changes the task, archive the old gate and re-evaluate it instead of defending an agent-created blocker.
+7. **Re-engagement:** a deferred gate comes back. Lane-level founder gates (spend, public posting, release) carry the ISO date they were last presented; at session start, re-present any gate older than 30 days with what changed since — new numbers, new evidence, new deadline — and re-date it with the founder's response. Silence defers again; it never converts to approval and never means forever (see `project-state.md` "Founder-Gate Re-Engagement").
+
+Do not ask the founder to choose between two ordinary implementation approaches. Resolve bounded choices internally. Ask only when ownership, money, credentials, legal identity, public voice, platform policy, or irreversible consequences require the founder.
+
+A direct request authorizes the reversible preparation it names. Draft the guide, comparison, copy, or plan first; use choices afterward to explain rigor, evidence treatment, or optional next routes. Do not convert already-requested preparation into a new permission gate.
+
+The protocol above covers moments that need a decision. Routine progress needs telling too. Use one short milestone digest when the state changes or the session ends:
+
+1. State the concrete result that the founder can now see or use.
+2. State the next work in one sentence.
+3. State one current founder action, or say that no action is needed.
+
+Do not narrate state-writing mechanics, internal work areas, worker order, check counts, or file propagation. Do not repeat the same decision in later updates unless new information changes the recommendation or the decision becomes current again. A long-running session can keep detailed logs in the repository. The founder receives the integrated result.
+
+## Business Bootstrap Sequence
+
+Create `operations/BUSINESS_ACCESS.md` and `operations/business-access.json` during orient, before provider setup sprawls. Keep `currentPhase` visible and at most one structured `activeFounderGate` with phase, origin, class, definitions, choices, bypass/defer policy, lifecycle, next actions, and proof. Set the active gate to `null` while no founder decision is needed; the agent keeps working from `nextAgentAction`. Also record the next business operation so access setup cannot become a dead end. The first gate should be one combined step-away readiness choice. It must cover autonomy, budget, access, tools, upload roles, deployment targets, and optional final-release authority. Run the sequence continuously:
+
+1. **Business identity:** confirm the working business/app name, founder-owned contact email, region, and whether a legal entity already exists. Do not force incorporation before it is needed.
+2. **Ownership spine:** establish a founder-controlled business email, recovery email/phone, password-manager or passkey posture, and 2FA ownership. The founder remains the owner of record.
+3. **Secret operations:** install or verify Doppler, authenticate the founder/operator locally, create or select the project and real configs, route secret names, and prove a safe injected command without printing values.
+4. **Account inventory:** determine whether Apple, Google, domain/DNS, support email, X, Meta/Instagram, TikTok, YouTube, analytics, revenue, email, support, and deployment accounts exist.
+5. **Create or claim:** use authenticated browser control to create or claim missing business assets when authorized. Explain platform verification, handle/name tradeoffs, and recovery implications before sticky identity changes.
+6. **Delegate:** grant the narrowest revocable operator role or OAuth scope. Avoid shared personal logins.
+7. **Verify:** read back the exact account, business asset, role, permissions, environment, recovery owner, and 2FA owner. Capture sanitized proof.
+8. **Operate:** move into reversible local prep, content drafts, customer-response drafts, and launch sequencing. Access setup is an unlock, not the deliverable. A held step-away gate does not authorize `workflow.research.research-backed-spec`. That node stays frontier-blocked until the live App Store portfolio observe succeeds.
+9. **Stay unattended:** record the matching protected control waiver and exact workflow-scoped standing envelopes, then consume them without asking again. Combine any new missing permissions into one handoff and continue independent work.
+
+### Plain-Language Research Example
+
+Do not turn "prepare an interview for my friend" into an unexplained formal-research blocker. Define terms first: **compensation** means whether the person receives payment or a gift card; **recruitment** means how participants are found; a **moderator** is the person asking the questions. Then present one decision:
+
+- **Phase:** Research-backed spec. **Outcome:** learn whether the problem and proposed product make sense to a real person.
+- **Quick friend chat (Recommended):** prepare a 10-15 minute conversation guide now. Consequence: useful directional feedback, but not formal market proof; the agent drafts the guide and marks the evidence accordingly.
+- **Formal interview:** add a clear purpose, voluntary participation, recording choice, note handling, participant criteria, and a structured script. Add compensation or recruitment only when people will actually be paid or sourced. Consequence: stronger research evidence, but more setup before the conversation.
+- **Skip interviews for now:** synthesize existing sources and product evidence. Consequence: research remains partial and the choice returns before spec freeze.
+
+The founder's request to prepare the friend conversation is authorization to prepare the reversible guide, not to spend money, recruit strangers, or claim formal validation. An unpaid informal chat that stores no sensitive data is not automatically a protected legal/privacy gate; apply stricter review only when the actual topic, population, claims, recording, or data handling requires it.
+
+### The Consumer-Norm Evidence Bar
+
+The example above generalizes. The evidence bar for a consumer app is consumer-app norms: store and competitor data, review mining, social language, keyword demand, and a live waitlist or purchase funnel. It is **not** research governance. Do not invent formative-interview programs gated behind privacy reviewers, external encrypted data planes, participant compensation approvals, or role-separated dry runs for a consumer utility — that apparatus produced zero customer proof in two months on a real launch before the founder retired it by hand. Escalate the bar only when a hard constraint forces it — medical or health claims, minors as a target audience, a regulated category — and even then propose the minimum that satisfies the constraint, as a founder decision with the cost stated.
+
+## Doppler And Login Model
+
+Refresh official Doppler docs and local CLI help before setup. Current source anchors:
+
+- `https://docs.doppler.com/docs/cli`
+- `https://docs.doppler.com/docs/service-tokens`
+
+Use Doppler for API keys, OAuth/refresh tokens, webhook secrets, service tokens, CI/deploy credentials, store API credentials, and automation secrets. Keep only names, project/config locations, owners, and proof paths in the repo.
+
+Use browser/password-manager/passkey/platform delegation for interactive human login. Do not treat Doppler as a browser-password autofill system. Never request a password, recovery code, 2FA code, passkey, cookie, or session token in chat or commit it to an artifact.
+
+Default setup loop:
+
+1. Check `doppler --version` and live help.
+2. If login is missing, explain that the founder will complete the Doppler browser login; run `doppler login` only with their approval.
+3. Confirm the active identity with `doppler me` without recording personal data beyond a safe account label. Verify that the workspace is founder-owned, recovery and MFA remain founder-controlled, and durable ready-state automation uses a named scoped delegated role, service token, OIDC route, or integration with an explicit revocation path. Founder-personal CLI login is bootstrap-only.
+4. Create or select the business project and real configs through current CLI/dashboard flows. Never guess config names.
+5. Run `doppler setup` in the correct repo scope.
+6. Have the founder enter new values directly into Doppler or a secure provider prompt. The agent records secret names only.
+7. Validate with `doppler run -- <safe smoke command>` that proves injection without echoing values.
+8. Use config-scoped service tokens, provider integrations, or OIDC for CI/production. A personal CLI token is local-operator access only.
+
+If the founder says "I can give you Doppler," translate that into the smallest secure action: authenticate the CLI or invite the appropriate business identity, then let the agent inventory projects/configs and do the rest. Never ask for a raw Doppler token in chat.
+
+## Social Account Access
+
+Track X, Meta/Instagram, TikTok, and YouTube explicitly even when deferred. Use the platform's current official role model and current browser UI; stored instructions may drift.
+
+Preferred order:
+
+1. Platform-native delegated role or business portfolio/member access.
+2. OAuth connection to the approved operating tool with reviewed scopes.
+3. Dedicated business-owned operator account with least privilege.
+4. Founder-authenticated browser session when no delegation exists.
+5. Shared credential only as an exceptional, documented platform limitation, stored in an approved password manager rather than chat/repo; founder retains recovery and 2FA. Token/service-account exceptions must record the delegation gap, scope source, rotation/expiry contract, secret name, limitations, and revocation path.
+
+Current official source anchors:
+
+- X Delegate: `https://help.x.com/en/managing-your-account/how-to-use-the-delegate-feature`
+- Meta Page/business access: `https://www.facebook.com/help/289207354498410?locale=en_GB`
+- TikTok Business Center members: `https://ads.tiktok.com/help/article/add-users-tiktok-business-center?lang=en`
+- YouTube channel permissions: `https://support.google.com/youtube/answer/9481328?co=GENIE.Platform%3DDesktop&hl=en-EN`
+
+For every social account, verify:
+
+- canonical handle/account and business asset
+- founder owner-of-record
+- operator identity and granted role
+- explicit granted scopes for observe, draft, publish, reply, moderate, analytics, spend, identity change, and deletion; unavailable scopes remain false
+- whether ads, billing, or finance permissions are excluded
+- who delegated access and the exact revocation path
+- recovery and 2FA owner
+- connected OAuth/API secret names, never values
+- a secret-scannable read-back log and the next operating action; route screenshots/video through `operations/AGENT_OPERATIONS.md` with its redaction attestation instead of treating a filename as proof of sanitization
+
+Do not stop after saying "create an account." Offer handle options from the approved brand, check availability when authorized, open the correct signup/business screen, guide the founder through the single ownership step, complete profile setup, secure access, and move directly into the first content/research/support task.
+
+## Authorization Boundaries
+
+Account access and approval are separate records. Resolve both during onboarding when possible. Continue using `frontier-agent-operations.md` and its approval envelopes.
+
+- Observe and draft autonomously inside the business scope.
+- Connect accounts after the founder approves the exact account and role during the readiness setup.
+- Publish, reply publicly, send broadcasts, spend, change pricing, alter legal/business identity, manage payment methods, submit stores, release, or delete only under the matching current approval envelope.
+- Use a matching standing envelope without another confirmation.
+- Website deployment, asset generation, store media/metadata, and test-build uploads should get both the required control waiver and standing envelopes during onboarding. Each envelope names exact catalog workflow IDs and exact output/provider resource prefixes; never record `workflow.*`.
+- The founder owns final public voice policy. A social or public-voice post never runs on a standing envelope, however exactly its voice policy matches. It always needs a fresh, per-item founder decision. A standing envelope only ever covers already-approved routine copy — store metadata, previously-drafted landing pages. It never covers open-ended founder-voice speech. See `docs/authority-envelopes.md`'s "Public voice" grant.
+- Never widen a social role, OAuth scope, finance permission, or admin privilege merely to remove friction.
+
+## Proof And Continuity
+
+The durable source set is:
+
+- `operations/BUSINESS_ACCESS.md`
+- `operations/business-access.json`
+- `operations/AGENT_OPERATIONS.md`
+- `operations/agent-operations.json`
+- `SECRETS.md`
+- `state/business-state.json`
+
+After every setup action, update the exact account status and business asset, named operator identity, granted scopes, delegation and revocation path, next founder action, next agent action, next business operation, proof path, and blocker. `not_needed` requires a reason. At resume, continue from those next actions without asking the founder to reconstruct prior setup.
+
+## Failure Conditions
+
+Flag and repair these immediately:
+
+- founder receives a jargon-heavy checklist or is asked "what do you want to do next?" while the agent has enough state to choose
+- founder receives an invented blocker or a seven-field free-text questionnaire where a phase-labeled choice with a safe defer route would work
+- agent stops after instructions instead of opening the setup surface and continuing
+- password, 2FA, recovery code, cookie, raw token, or secret value is requested in chat
+- Doppler is described as browser password storage or a raw personal token is requested
+- a personal social login is shared when delegated access or OAuth exists
+- a social account is called ready without exact handle, role, recovery/2FA ownership, sanitized proof, and an operating next step
+- account access is treated as approval to publish, spend, reply, change identity, or delete
+- the founder is interrupted for each account instead of receiving one consolidated readiness request
+- a second sequential tool gate opens after workflow intake, or a deferred research-intelligence tool parks the evidence lane with no labeled fallback
+- a matching standing envelope exists but the agent asks for the same approval again
+- the agent reaches deployment or store upload before checking required tools, roles, signing, and authentication
+- the agent completes access setup but does not begin the next business operation