Jaiva v1: what is done, what is left

As of 2026-10-05, main at 98f1a9c3. From the system map and the #994 v1 release tracker. Slice E from the #1168 Client Delegate map and the accepted ADR-0030 Client Delegate.

15 of 27 release parts work today slices A to D
  • 15 working
  • 6 built, switched off
  • 6 planned

Release slices

The release proof: La Santa Picá gets ten scheduled posts in a row through this loop, and then a second client gets five. Slice E is in v1 but does not gate the release, so it stays out of the top bar. Open a slice to see its parts. Open a part to see its evidence.

A Generate a post, founder approves in Studio Done. You ran one real post on staging through generate, one pivot, admission and approval on 2026-09-27, and accepted the #979 generation proof. In production, Studio opened for both founders behind Google sign-in on 2026-09-27 (#1263), and it answers at studio.jaiva.cl since the same night (#1294). It is still empty. Since the 2026-09-28 production deploy, generation runs in production. Both provider keys are set (#1268 production provider keys). The two-minute schedule, the verified caption billing and the all-clients scope are live (#1269 production generation). The #1266 production client records form is live too, so any client you authorize there can generate, with no deploy per client. It still needs that first client: La Santa Picá. Since 2026-10-02 the «Preparar propuesta» panel (#1369 dish and proposal screens) is in production too, so you can add the dish and write the proposal in Studio once the kit is active. 12 of 13 working
  • Studio decision workspace: approve, correct or reject the exact versionworks
    What it does
    The founder sees one post, edits the caption if needed, and approves, corrects or rejects that exact version. Approval records a send intent and a ledger event in one transaction.
    Evidence
    platform/src/lib/studio/studioPacket*.ts, from the Studio packet PRs #897 and #929.
    Owner doc
    Spec 893 Studio packet contract
  • Brand kits with versions and pinned reference photosworks
    What it does
    Each client has a brand kit. Each change makes a new version. A founder activates one exact version, and it can pin approved client photos.
    Evidence
    studioBrandKit.ts, table client_brand_kit_revisions.
  • Founder photo upload and "can we use it" decisionworks
    What it does
    A founder uploads client photos and marks each one usable or not. Only client-owned photos can be marked usable today.
    Evidence
    registerFounderSourceAsset.ts, table studio_source_eligibility_decisions.
  • Studio login behind Cloudflare Accessworks
    State
    Works on staging and in production. Production (#1263 Studio in production) opened on 2026-09-27 with Google Workspace sign-in for the two founders only. Both founders signed in; other accounts are refused. Since the night of 2026-09-27 production Studio also answers at studio.jaiva.cl, behind the same founder-only sign-in (#1294 Studio hostname). Both founders work there and a non-founder is refused. Packet commands and brand bootstrap are on in production since 2026-09-27 (#1267). Since 2026-09-28 the client records form (#1266) and generation (#1269) are live in production too. The production Studio stays empty until you write the first client (#1265 production Studio map).
    Evidence
    #933 Studio login, studio-auth.ts.
    Owner doc
    Spec 933 Studio Cloudflare login
  • Generation run recordsworks
    What it does
    Stores every generation run and image attempt against the exact proposal version.
    Evidence
    Tables studio_generation_runs and studio_generation_attempts.
  • Image provider adapterworks
    State
    Merged in PR #1000 (#257 provider adapter). Real image calls ran on staging in the #979 generation proof, at $0.19 per image. See the #979 evidence.
    Evidence
    platform/src/lib/imagegen/openAIImageProvider.ts
  • Durable image generation run in the cloudworks
    What it does
    Runs generation as a job that survives crashes: database-time claims, one-shot permissions, bounded storage recovery, tenant isolation.
    State
    Merged in PR #1049 (#258 durable generation). It ran on staging in the #979 generation proof. A database cut after the image call left that attempt marked "uncertain", and the next attempt succeeded. Staging generation is now on through settings kept in the repository (#1269 committed generation flags), so a deploy no longer clears it. Production generation is live since the 2026-09-28 deploy (#1269) and waits for its first client. The new Queue handoff (#1378) is implemented but off in both environments. It can advance one exact image or caption job per delivery while retaining database recovery state. On 2026-10-01 a staging test ran three packets through the Queue, and each got its image and its caption (Queue handoff #1378 evidence). Repeated and invalid messages started no paid call. When the Queue starts cold, it works on one image at a time first, so one packet waited about two minutes for another. Automatic repair (#1379 stranded-run repair) is merged and passed a two-packet staging test on 2026-10-02 (repair #1379 evidence). One packet lost its Queue message at the start, and the other lost its caption step. The next two-minute check finished both, and neither paid for a second image. Since 2026-10-02 the staging Queue flag stays on across deploys (#1489 staging flag durability). The 100-packet target (#1380 generation capacity) is unproven. See the #979 evidence.
    Evidence
    studioGeneration.ts, worker.ts, migration 0036.
    Owner doc
    Spec 258 durable generation
  • Caption written from the finished image, with a conflict holdworks
    What it does
    Gemini writes the caption after the image exists. If the caption conflicts with the menu facts, the post is held. A technical failure restarts only the caption and keeps the image and its cost.
    State
    Merged with #258 durable generation. Paid Gemini captions ran on staging in the #979 generation proof. A caption that passed its deadline was restarted from Studio, and the image was kept. The conflict hold has not been tested on staging. A separate staging-only Cloudflare managed caption route (#1378) is built and default off; production and the default remain direct. It retains the same model, request and retry limits and refuses old-route jobs before any new provider spending. On 2026-10-01 it wrote three captions on staging through Cloudflare, each in about 15 seconds. You have not judged their quality yet, and the approved three-packet test is used up.
    Evidence
    geminiCaptionProvider.ts, table studio_caption_cycles.
  • Generate from Studio, then keep or decline the image and captionworks
    What it does
    A founder starts generation from Studio. The image and caption enter as one exact pair. A founder can decline a candidate and ask for a new creative direction for the same slot.
    State
    Merged in PR #1148 (#978 pair admission). You generated, pivoted once, admitted and approved on staging in the #979 generation proof. Nothing was sent or published. Production Studio had no screen to add a dish or write a proposal, so Nuevo paquete stayed empty. The «Preparar propuesta» panel (#1369 dish and proposal screens) adds both: you type the dish name and price, then pick the dish, the scheduled delivery and a kit photo. The server works out the rest. It is in production since 2026-10-02.
    Evidence
    StudioDecisionWorkspace.tsx, studioPacketAdmission.ts, migration 0038.
  • Dated menu facts and approval guardsworks
    What it does
    Menu facts carry the date they take effect. A fact change cancels approvals for posts that are not yet published. Generation, admission and approval all check the facts.
    State
    Merged in PR #1039 (#977 menu facts). Generation, admission and approval checked the facts in the #979 generation proof. A fact change that cancels an approval has not been tested on staging.
    Evidence
    studioMenuFact.ts, tables client_menu_fact_revisions and studio_packet_fact_invalidations.
  • Staging test-photo fixture and crash repairswitched off
    State
    Merged in PR #1001 (#976 fixture repair). Verified with simulated faults. The #979 generation proof used your own photo, so this fixture path did not run.
    Evidence
    studioStagingGenerationFixture.ts
  • Read-only report for each post in a proofworks
    What it does
    Gives a founder one report per post, read from stored records: what ran, what it cost, what failed, what comes next. It never calls a provider or changes data. Missing evidence stays "unknown".
    State
    Merged in PR #1162 (#1160 packet report). The #979 generation proof posted a completed report and an interrupted report. The #985 client approval and #993 publication proofs add their own evidence.
    Evidence
    GET /api/internal/studio/packet-report
  • Staging proof of the whole sliceworks
    What it proves
    A real generation run on staging, one complete and one interrupted, each with its report.
    State
    Done 2026-09-27. You accepted it. Your active time was about 10 minutes, and each image cost $0.19. See the #979 evidence.
    Links
    #979 generation staging proof · Spec 974 cloud packet
B Client approves the exact post on WhatsApp Inbound receipts, the proposal adapter and the bounded send sweep are built and switched off. Since 2026-10-04 a Meta test number reaches staging (#1539 staging WhatsApp line). Left: reply handling and the #985 client approval proof. 1 of 6 working
  • WhatsApp router: old-style post approvals and supervised repliesworks
    What it does
    Routes each incoming WhatsApp message on the shared number and lets a founder supervise replies. It records old-style post approvals from a button reply. It does not bind the reply to an exact packet version; slice B builds that.
    Safety change
    Live since the 2026-09-25 production deploy (#1195). Every AI draft now waits for León or Juanro; the router no longer auto-sends. No login-code (OTP) code exists, although the map once listed it.
    Staging line
    Since 2026-10-04 a Meta test number delivers to the staging Worker, and a founder text there gets a Gemini draft that waits for a founder (#1539 staging WhatsApp line). On staging the drafts call Gemini through the Cloudflare AI Gateway; production keeps the direct route (#1531 drafts through the AI Gateway). Merged code now records a supervised reply's outcome after the send (#1441, 2026-10-04) and removes the old /inbox reply route (#1442, 2026-10-02).
    Evidence
    platform/src/lib/whatsapp/router.ts, ADR-0006.
  • Durable inbound receipts and crash recoveryswitched off
    What it does
    Stores every signed reply before Meta gets its 200. A recovery job every two minutes uses a recent wake marker to finish work a crash left behind, with bounded retries; hourly maintenance also checks for work. Signed replies, generation commands, send approvals, evidenced retry resolutions and source uploads establish that marker before creating work. Bursts reuse it for up to 30 minutes; an unverified wake refuses new work (#1371). This wiring does not turn on transport or upload recovery. A stored receipt never counts as an approval on its own.
    State
    Merged in PR #1180 (#981 durable inbound). Migration 0039 is on staging. Staging has the recovery flag and the two-minute schedule. It still does nothing until WHATSAPP_INBOUND_DESTINATIONS is set on purpose. Production has recovery off.
    Links
    Spec 980 inbound recovery · test-typing follow-up #1182 mock type fix
  • Proposal template and media adapterswitched off
    What it does
    Builds the exact image, full-caption, time and button request for Meta, with bounded typed evidence.
    State
    The adapter is composed by #983's Worker behind a default-off, staging/test-phone gate. Verification uses fake HTTP; no live Meta proof or activation is claimed.
    Evidence
    packetProposalProvider.ts, metaPacketProposalProvider.ts and packetProposalProvider.contract.md.
    Links
    #982 Meta template and media
  • Send sweep, send recovery and test-phone gateswitched off
    What it does
    Sends each approved post once. A lost send result stays "uncertain" until evidence resolves it. On staging it sends only to an authorized test phone.
    State
    Merged PR #1198 contains the bounded sweep, private image checks with streaming size and time limits, inbound observation recovery and scheduled wiring. PR #1299 repaired fresh-provision runtime access. Studio shows prior attempts, operation outcomes, retry times, evidence and immutable resolution receipts. A lost response can reload and replay the same resolution without sending again. Since #984 a correction after an accepted send makes a new version inside the client's seven-day window and keeps the send history; an unknown send result still waits for founder reconciliation. Exact-head tests, build and independent review passed; migrations and the repaired grant are on staging. Runtime stays off because the enable flag and authorized test destinations are absent. No customer message or live Meta proof is claimed.
    Links
    #983 send sweep
  • Client reply: approve, ask for changes, sent correctionswitched off
    What it does
    Only the designated approver can approve, and only the current version. A change request pauses publication. Free text or silence never approves. After seven days without approval the post closes unpublished.
    State
    Built in the #984 pull request: the reply rules, the change pause, the seven-day clock from the first confirmed delivery, the sent correction, the Studio panel "Decisión del cliente" and founder alerts. The client-packet-decision journey proves it end to end against the fake Meta. It stays off because packet sending is off on staging. #991 now admits the publication intent atomically. Publication stays disabled until #992 supplies execution and its final permissions.
    Links
    #984 client reply and change pause
  • Staging proof of the whole slicewaits on you
    What it proves
    The same post from the #979 generation proof reaches a real test phone and a real button reply comes back, with the report extended.
    Left
    #984 client reply is built and switched off. From you: the Meta template and one enrolled founder phone. The staging number secrets are set since 2026-10-04 (#1539 staging WhatsApp line).
    Links
    #985 client approval staging proof
B2 Publish once, at the agreed time Publication intent and publication workflow built, disabled; they run only in the test build. Left: a founder decision on the deploy binding, and the #993 publication proof. 1 of 5 working
  • Zernio client, publish and reconcile effectsworks
    What it does
    Publishes to Instagram through Zernio and reconciles the result. Proven on staging on 2026-07-04 with the older manual path. The new sweep will use it.
    Evidence
    platform/src/lib/zernio/, platform/src/lib/effects/. The separate Jaiva-owned service under Replacement map #1320 now has connection, encrypted token custody, queued publication and dated account snapshots on main (Secure connection #1384, Durable publication #1385, Account snapshots #1386), with 343 controlled tests and real PostgreSQL passing at the reviewed OAuth adapter revision. Replays return the same stored post; an uncertain publish result pauses for reconciliation. Snapshots keep real zeros and leave missing values absent; account totals do not prove one post's performance. The staging service is deployed. Its database and queue are provisioned, secrets installed and rollback exercised. Service-owned OAuth now succeeds with separately verified app-scoped and professional IDs. Account listing proves the selected fixture is active; all three actual permissions and encrypted token custody with future expiry are verified. The founder-approved neutral image is now visible on the staging fixture with the exact caption. Replay returns the same post and media; changed content and conflicting request headers are rejected. One genuine account snapshot for September 30 is stored with four provider-supplied zeros and no unavailable metrics. It is an account observation for the previous day, not performance evidence for the new post. The offline build draft records its scope; the staging run draft plans one post and a snapshot on @jaiva_staging_fixture. B2 and the platform collector use Zernio. The production service now runs on https://social.jaiva.cl with its own database, queue and secrets (Production bring-up #1430). It has no connected accounts. Its separate Meta app, Jaiva Social, still needs App Review before any client connects.
  • Public media copy with a hash checknot wired in
    What it does
    Copies the approved image to a public address and checks it byte for byte. The receipt proves the copy, never the post.
    State
    Merged in PR #1117 (#990 media copy). The #992 publication workflow calls it, in the test build only.
    Evidence
    publicPacketMediaCopy.ts, table studio_public_media_copy_receipts.
  • Publication intent and timing guardbuilt, disabled
    What it does
    Client approval records one intent and window at the original time. Late processing pauses for founder review; a second tap changes nothing. The occurrence guard preserves possible or confirmed publication across successors.
    State
    Built in the #991 change. Studio shows original Santiago time, scheduling, guard and next actor. Publication is disabled in both environments, with no scheduler adapter or provider call. #992 adds execution; #993 proves the real loop. A new time and founder release remain #1861.
    Links
    #991 publication intent · Spec 989 publication
  • Publication workflow and recoverybuilt, disabled
    What it does
    Publishes at the due time, rechecks the change pause last, and never repeats a create call that may have gone through. Unclear results go to a founder in Studio.
    State
    Built in #992. It copies the image and publishes once, each step under its own one-use permission. The client's change pause and the occurrence guard are checked last. Results bind to their own window. Studio and the report show the copy, the provider ids, the observations and the incidents. It runs only in the test build: no deployed Worker has the workflow binding yet, and that waits on a founder decision.
    Links
    #992 publish sweep
  • Staging proof: one real post, and crash testswaits on you
    What it proves
    One real post on the throwaway Instagram, with outside evidence, and recovery at the dangerous crash points.
    Left
    #992 publish sweep and the #985 client approval proof done. From you: the staging publish target and the real staging bucket URL.
    Links
    #993 publication staging proof
C Client accepts the plan and pays Not started. The spec waits on the La Santa Picá agreement and the Mercado Pago answers. 0 of 1 working
  • Accept-and-pay link, charge and reconciliationwaits on you
    What it does
    One link where the client accepts Plan Base and saves a card. Jaiva charges once a month on the anniversary through Mercado Pago, and reconciles the charge.
    Left
    Spec not written. From you: the La Santa Picá transitional agreement and the date of its next paid period.
    Links
    #881 acceptance and charge · Spec 836 v1 product
D Midpoint and closing reports Metrics are collected today. The report spec comes after the #993 publication proof. 1 of 2 working
  • Metric snapshots from Zernioworks
    Evidence
    Table metric_snapshots, effect captureMetricsSnapshots.
  • Midpoint and closing period reportsplanned
    What it does
    Two reports per service period for the client. Each is written after its window closes, and a founder approves it before it goes out.
    Left
    Spec not written. It follows the #993 publication proof.
E Client Delegate: an agent talks to each client for us Not a release gate. Research, your #1169 decisions and ADR-0030 are done. The #1172 prototype is judged and closed. Left: your decisions on the proactive-message amendments and on the Delegate tool shape, then the phase-1 spec and the Capability Surface. 1 of 6 working
  • ADR: the Client Delegate pattern and its authority matrixdecided
    What it does
    Records what the Delegate may do for a client, what only the client may do (approve, accept, pay, cancel), and what only founders may do. It retires the "Orchestrator" name.
    State
    Drafted as ADR-0030, ratified 2026-09-24. It records your #1169 authority matrix and send gate decisions: each send waits as a pending intent that either founder approves on an Access page.
    Left
    Nothing. The phase-1 spec builds on it.
  • Client Capability Surface: an MCP server scoped to each client, on stagingplanned
    What it does
    The one door the Delegate uses to act for a client. It takes the client from the caller's token, never from a tool argument, so one client's message can never reach another client's data. Studio keeps its own routes: your 2026-10-02 decision scopes the Surface to the Delegate only, so founder-only actions such as packet approval and generation are never Delegate tools.
    State
    Inventory done: #1171 capability catalog (merged in PR #1184). It found that no WhatsApp send passes the effect chokepoint today, and that Studio routes take the client id from the caller. A backend audit on 2026-10-02, challenged by two independent reviewers, found the base ready: business rules sit in plain functions with typed results, commands are safe to retry, and the database already accepts Delegate ledger records. The Delegate functions themselves do not exist yet. They will be new code beside Studio, not a rewrite of it.
    Left
    The #1174 MCP server research is done, and ADR-0030 is ratified. Left: the phase-1 spec and tickets. Before them: your decision on the tool shape (#1214) and #1444 a check of the live database role. Done since 2026-10-02: #1445 Delegate kind in the ledger code, #1442 inbox reply sent with no record (the route is gone) and #1441 supervised reply logged as sent before it is sent (fixed 2026-10-04).
  • Phase 1: founders run the Delegate from their own computersplanned
    What it does
    A founder-guided Claude Code or Codex session answers and follows up with one client. A founder approves every send. Every send is ledgered and gated on the server.
    State
    Research done: #1175 workstation operation and #1176 context, memory and injection defense.
    Left
    The #1172 La Santa Picá week prototype closed on 2026-09-26 with León's verdict. Draft PR #1243 holds the phase-1 staging contract. Unsolicited client text still has no processing path, so the phase-1 spec must give it an owner. Real sends also need the #985 client approval proof.
  • Proactive messages: trigger catalog and Meta templatesplanned
    What it does
    Heads-ups, follow-ups and suggestions, each tied to an approved template, with a frequency cap and a budget per client.
    State
    The #1170 Meta template and window rules in Chile research is done. Suggestions go only inside an open 24-hour window, v1 has no marketing template, and templates outside the window stay factual. The rule: the client's opt-in must be recorded before the first proactive message.
    Left
    A decision on the ADR-0030 amendment in #1242 proactive recommendations and check-ins (draft PR #1245) and on #1254 shared proactivity accounting. Then the gate in #1255 consent, cadence and budget and #1288 consent capture in onboarding. Nothing records client opt-in today. The price of free-form messages after 2026-10-01 is open in #592 WhatsApp pricing.
  • Stop the old router auto-replying on the client lineworks
    What changes
    #1195 removed model auto-send from the router and queues every draft for founder approval. It is live in production since the 2026-09-25 deploy.
    Evidence
    #1195 founder approval for every draft, platform/src/lib/whatsapp/router.ts.
  • Phase 2: hosted Delegate, still supervisedlater
    What it does
    The Delegate runs hosted and drafts; a founder approves each send. Each message type moves to auto-send only on its own written record.
    Left
    Research opens after phase 1 has run. The founders decided a scoped API-key exception for this agent only.
    Links
    #1168 Client Delegate map
7Waiting on you
  • packet_proposal template written and sent to MetaUnblocks the #985 client approval proof. Meta review takes days
  • One founder phone enrolled as the staging approverUnblocks the #985 client approval proof
  • Staging publish target set to the throwaway Instagram, and the real staging public bucket URLUnblocks the #993 publication proof
  • La Santa Picá transitional Plan Base agreement and next paid period dateUnblocks slice C, accept and pay
  • Decide the proactive-message amendments in #1242 and #1254Unblocks slice E: the ADR-0030 amendment and the phase-1 spec
  • Decide the Delegate tool shape on #1214Unblocks slice E: the Capability Surface tickets in the #1238 phase-1 spec
  • Que Panzza October renegotiation outcomeNeeded before Que Panzza counts toward the release proof

Around the loop

These parts feed or support the loop. They do not count toward the release bar.

Sales WhatsApp with founder approval Planned for the Sales number. Prospect messages, founder decisions and client operations will use separate lines and records. 0 of 1 working
  • Remember Sales conversations, propose replies and ask a founder before sendingplanned
    What it will do
    Keep an evidence-linked Sales conversation, draft one reply and an optional action, then show the exact proposal to León and Juanro on a separate Control number. An agent reply reaches a prospect only after a current structured founder decision and a final check of conversation freshness and Meta's 24-hour window.
    Number choice
    Prefer the existing Sales number only if official Business App and Cloud API coexistence is proven. If that fails, the existing number stays manual while a separate API-only Sales number is evaluated.
    State
    The architecture and supervised flow are defined in #782 and ADR-0029. The separate inbound transport for Sales and Control is being built switched off under #528 source-isolated transport. As of 2026-10-05 its receipts, recovery and the enabled route are merged. The enable flag is absent everywhere, so none of it runs. Production is still at migration 0051, and the newer migrations wait on your production dispatch. Health checks, Sales and Control configuration, the staging proof, the retention schedule and real number setup are still pending. The client approval line is a separate domain.
Photos, references and prospects Client photos and prospect pages work. The source registry is built and proven on staging with test data. The reference collector is built with collection off; production waits on founder gates. The queue is planned. 1 of 4 working
  • Pitch pageworks
    Evidence
    platform/src/pages/p/[token].astro, ADR-0023. The prospect bootstrap code was never wired in, and #1208 deleted it.
  • Reference briefplanned
    Evidence
    The migration 0022 tables stay. The first-stage code had no caller, and #1208 deleted it. The matching step is planned.
  • Account registry, Apify collector and Studio reference queueplanned
    What it does
    Collects public Instagram posts from reference and prospect accounts through Apify, with no Meta login. Founders approve or reject each one in Studio. Authorized photos, actual Reels and captions can enter Brand Kit analysis through customer-isolated custody and temporary run/snapshot/attempt access. Marketing-image generation retains its separate source_assets authorization gate.
    State
    The registry part is built. #1106 source registry closed on 2026-10-05 after PR #1328 and five follow-up PRs. It stores one shared identity per account and separate media per client and per rights class. Captures cannot change class or content after they are stored. The marketing generator refuses captured media before any provider call. The private staging buckets exist (#1479). A staging run with test data proved separate objects per client, a separate prospect bucket, a refused alias and a replay that finalizes once (#1106 closure). Production buckets, bindings and migrations wait on the founder gate. The bounded Apify collector for reference accounts is built, with collection off (#1107, #1110). Its production code is ready behind the founder gates (#1858); the production bucket waits on #1859, and the founder runs the enablement runbook. The Studio queue and the Brand Kit builder reads are not built.
    Links
    #1004 source-account registry · ADR-0028
  • Ask a photographer for permissionplanned
    What it does
    Ask the author of a third-party photo. Yes: use it and tag them. No answer: look-alike only, no pixels. No: never use it.
    Links
    ADR-0021
Brand Kit builder candidate On 2026-10-02 staging runs made a draft, took a founder edit, activated it, refreshed it, and wrote one post whose caption used the active voice. Staging flags stay on across deploys (#1489). Video analysis is still open. Prospect conversion remains planned. 0 of 3 working
  • Draft Brand Kit from scoped evidenceoff
    What it does
    The candidate reads authorized photos, video, PDF and text through a private scoped bridge. Missing sources stay as gaps. Studio shows the draft, its evidence and its history. A founder edits fields, and each edit makes a new version that protects the edited field. A founder activates one exact version. Registry PR #1328 (#1106), merged on 2026-10-02, adds producer pins for per-client photos, Reels, PDFs and captions, with temporary reads bound to the exact run, snapshot, attempt and grant. The builder does not read from the registry yet.
    State
    Generation runs through the Worker AI binding, one call per try. On 2026-10-02 one controlled run on a test client made a draft that cites photos, the menu PDF and text. A founder edit, an explicit activation and a refresh followed. The refresh kept the founder's voice text and offered its own text only as a suggestion. The model did not cite the test video, so video analysis is not proven. Execution is on in staging, and the staging deploy keeps it on (#1489). See the staging proof 2026-10-02.
    Links
    #323 Brand Kit builder · Studio contract · HTTP 403 evidence and limits
  • DESIGN.md rendered from each kit versionoff
    State
    In staging, the DESIGN.md file saved for the active version matched two local renders byte for byte. It is stored under the client's own folder.
    Links
    #264 revision-bound DESIGN.md. Neon stays the source of truth.
  • Verbal identity: voice rules for posts and messagesoff
    State
    Schema2 voice, audience and direction are implemented. On 2026-10-02 one staging post ran image and caption. Its caption used the active version, its hash and the founder-edited voice. See the caption proof.
Platform foundations The ledger, kill-switch, stand-up reads and the Studio change feed work. Ledger coverage is partial, and the kill-switch covers publishing only. 4 of 4 working
  • Typed effect chokepoint that writes the ledgerworks
    What it does
    Typed effect functions write the domain_event ledger in the same transaction as the change. Studio packet commands also ledger in their own transaction.
    Gap
    Coverage is partial. Supervised WhatsApp replies write a ledger row after the send (#1441), but only publishing passes the chokepoint and kill-switch. Since #1195 the router sends no AI reply without a founder. Source: #1171 capability catalog.
    Evidence
    platform/src/lib/effects/, ADR-0012.
  • Kill-switchworks
    Evidence
    Effect killSwitch. Proven on staging on 2026-07-04.
    Gap
    It stops publishing only. No WhatsApp send checks it yet.
  • Stand-up snapshot and source health readsworks
    Evidence
    platform/src/lib/standup/. Read only. Staff agents observe and never approve or publish. Version 3, merged on 2026-10-03, also counts each client's ready and planned posts from Jaiva's own schedule, without Zernio (#1429 stand-up runway). It needs migration 0058, which production does not have yet.
  • Studio change feed for live updatesworks
    What it does
    Keeps one change counter per client. An open Studio checks it every 5 seconds and reloads only what changed. It pauses after 5 minutes without input behind «Pausado · Actualizar» and catches up on the next input.
    State
    Works on staging since 2026-09-28. A change from another tab showed in 2.6 seconds and pipeline steps in about 2 seconds; see the #1283 evidence. Production has the tables since 2026-09-28. Studio images now answer a repeat request with 304 and no image bytes when they did not change; checked on staging on 2026-09-28. Admitting a packet works on staging since 2026-09-29: a new candidate got its caption on the third attempt after two Gemini outage replies. Studio also fetches the next two review images in the background; on a wide screen the small pictures in the list already download them, so the gain shows mainly on a phone.
    Evidence
    GET /api/internal/studio/changes, tables studio_change_log and studio_change_cursors.
How agents ship code Automatic review levels are live since #1159 ceremony tiers. Since 2026-10-03 every staging deploy is checked, and a bad one is put back (#1459 staging smoke). 2 of 2 working
  • Pull request ceremony tier from changed pathsworks
    What it does
    Reads each pull request's changed paths only to choose T0, T1 or T2. T2 paths need a founder merge. No model grades pull requests, no tests are locked and there is no separate verifier. The implementer writes product UI journeys in the same pull request. Production, customer contact and publication stay human-gated at every tier.
    Evidence
    Changed-path rules in platform/scripts/ci/ceremony-tier.ts. The verifier lock, verifier-first T2 journeys and founder test approval were deleted on 2026-10-09 (#1840, #1841), under #1836 deletions 1–4. Repository policy
  • Staging check after every deploy, with automatic put-backworks
    What it does
    After each staging deploy, a test account signs in to Studio, makes a post from a fixed test photo and approves it. If any step fails, the deploy is undone and the version from before comes back. It uses one staging test client with no Instagram connection, so nothing is sent or published. Production is never touched.
    Evidence
    On 2026-10-03 a release broken on purpose (PR #1532 restore drill) was caught 1.7 seconds after the deploy and put back 3.4 seconds after it. The next deploy (PR #1537 drill revert) passed all three steps. Publishing joins the check later (#992 publish in the smoke). #1459 staging smoke · runbook
After the release Client dashboard, portal login and self-serve cancellation. 0 of 1 working
  • After release: client dashboard, portal login, self-serve cancelplanned
    Links
    Spec 836 §3