# Escalation to Fable — open questions the executor must not decide > **Status: ANSWERED, 2026-07-15 — see `escalation-verdict.md` for the rulings.** > Every § below is ruled there; the resulting work sits on > `plans/rethink/scope-board.md` and in `agent-scope-1d-kickoff.md`. This file > stays as the evidence record. New items go to the scope board's Intake > section, not here. > > Originally raised by the executor at the end of the Phase 1C session > (2026-07-14), on the operator's instruction: *"all of this needs to be > escalated to fable. don't do it yet."* > > Phase 1C itself is **code-complete, deployed and published**, and is awaiting > the Gate 1C verdict independently of this file. Everything below is scope the > Phase 1C plan did **not** cover — it is raised, not smuggled in. --- ## 0. The standing ask (operator, 2026-07-14) > *"add up that fable should look at the system and see what is missing of > functionality based on what I said and outside it."* So this file is a starting point, **not a scope boundary**. Fable is explicitly asked to audit the live system for missing functionality — both the gaps the operator named (below) **and gaps nobody has named yet**. The items here are the ones that surfaced by accident, while looking at something else; that is a strong signal there are more. --- ## 1. A comment the agent should have moderated, and didn't **This is the item that started the escalation. It is evidence, not opinion.** A real Instagram comment, 2026-07-14 02:42, from `hamster.6760689`: > *"They cheated me out of 30k many years ago. I would rather give my money to > charity than invest in a state that supports genocide"* Trace `da76dd49-23b8-4a9e-9b2c-31eb6730bc1e`: `decision=skipped`, `decision_reason=policy`, `model=deepseek-v4-flash`, **145 tokens in / 129 out**. **It was an INTENDED skip, not an auto-skip.** The model ran, spent money, and chose `{"action":"skip"}`. It was not a backfill seed, not an LLM error, not a fail-safe. **And it obeyed its instructions.** `system-prompt.ts` `commentSections()` defines `hide` as *"severe: scams, spam links, abuse aimed at a person"*. This comment is a defamation claim plus a political attack on **the company and a state** — not "a person". The safety rail then ends *"When in doubt, skip."* So the model followed the contract exactly. **Classification: a case nobody specified — a spec gap, not a model failure.** Fable's call, not the executor's: - Should the `hide` taxonomy cover reputational / defamatory / political attacks on the company? (operator is with motion) - Is "the model decides moderation from the same prompt that writes replies" defensible at all (see §2)? (operator says two prompts be different and its a different pass by itself) ## 2. Moderation and replying are one prompt, one decision, one gate The operator's words: *"the ai prompt doesn't separate the reply prompt and the moderation prompt (delete, hide, leave, escalate for review …). is that a future plan or a neglected fact?"* **Answer given to the operator: a neglected fact.** Checked against the target picture, the specs and every plan file. The current state: - **One prompt, one decision set** — `reply | skip | hide` — with moderation as three words bolted into the reply contract. - **`delete` does not exist, DELIBERATELY.** Target picture §5.3 settled that the bot never deletes: it hides (reversible) and queues a human to confirm. That part is intentional and should not be "fixed" by accident. - **★ `skip` is terminal and unreviewable.** The output contract gives `skip` no confidence field, so it can never be held for review. **The bot's most common decision is the only one the operator can never inspect or overturn** — which is exactly how the §1 comment vanished silently. This looks like the real defect. - **Nothing anywhere plans to separate moderation from replying.** The idea is not late; it is absent. **Operator's ask:** separate activation for moderation and reply — each with its own `off | shadow | live`. **Executor's read, for Fable to accept or reject:** the asymmetry is real and argues for the split. **Hiding is reversible and reviewed; replying is public and embarrassing.** They share one switch today, which is precisely why neither can move: moderation could safely run LIVE right now, but it is chained to replies, which must stay shadow. ## 3. ManyChat keywords/triggers — import as `silent` triggers **Operator's ask:** *"I want the keywords and triggers from manychat automatically added (backfill or possibly an api automation if possible until cutover) so the ai chatbot doesn't double respond."* - **The mechanism already exists**: a trigger with action `silent` is explicit suppression, so an external automation (ManyChat) keeps owning that reply. It was built for exactly this. - **Operator chose the API route** and will add a `manychat` connection key. - **⚠ EXECUTOR CAVEAT, RAISED BEFORE ANY KEY IS GENERATED:** it is **not verified** that ManyChat's public API exposes keyword / growth-tool rules at all. Their API is built around subscribers, tags, custom fields and flows. *Sending* is certainly there; *reading your keyword rules* is unconfirmed. **Verify the API surface against ManyChat's docs before building an importer.** If it is not reachable, an export/paste path is the honest fallback — say so rather than ship half an importer. - **★ CORRECTION TO THE URGENCY (told to the operator):** **there is no double-reply risk today.** `instagram:comments` is in **shadow** — the bot decides and logs but never posts, so ManyChat is the only replier. The ManyChat import is a **prerequisite for the live cutover**, not an urgent fix. This reorders the work: the §2 moderation split is what is costing the operator now. ## 4. A dropped lead — `empty_output` swallowed a real enquiry Found while investigating §1, unrelated to it, and arguably the most expensive item here in the short run. Comment from `fazilet528`: > *"Can you provide no obligation information via email no phone calls"* → `decision=skipped`, `decision_reason=empty_output`, **0 tokens out**. That is a genuine warm lead. The model returned an empty string and `parseCommentDecision` fail-safed to `skip` (`comment-policy.ts:90`) — correct as a safety behaviour, but the enquiry was then **silently dropped with no review item and no alert**. Nobody would ever know. Two questions for Fable: 1. Why did the completion come back empty (0 tokens out)? Not yet root-caused. 2. **Should a fail-safe skip be silent?** A skip caused by *our* failure (`empty_output`, `no_json`, `invalid_json`, `llm_error_*`) is categorically different from a skip the model *chose*. Today they are indistinguishable in the UI. This is the same hole as §2's unreviewable skip, seen from the other side. ## 5. The UI sweep — it is not scheduled, and three screen groups are orphaned The operator asked *"when is the ui sweep? I thought maybe it is early on."* **Checked: there is no UI sweep phase.** The only "sweep" in the target picture is *Phase 3 — Channel-agnostic sweep*, which is about channels (Connections, webhooks, filters), **not** restyling. What the plan actually says (§10, "Process", lines 72–73) is: > *"Screens are then rebuilt on the tokens, section by section, each shown for > reaction before the next."* So the reskin was deliberately **distributed across phases 1–5**, never scheduled as one job. The `--cm-*` token prefix exists precisely to prevent a big-bang re-palette of the legacy screens (HANDOFF 2026-07-10 calls it "the forbidden big-bang"). **Live state — only the Agent is on the new design system:** | On `--cm-*` tokens | Still legacy | |---|---| | Activity · Review · Posts · Triggers · Knowledge · Behaviour · Playground · Models | Dashboard · Inbox · Contacts · Settings (54 legacy refs) · Templates · Campaigns · Flows · Automation · Reminders · Analytics · Segments · Login | **★ THE GAP:** map the remaining phases against that list — Home (P2), Settings/Contacts (P3), Analytics (P4), Automation/Reminders (P5) — and **three groups are covered by NO phase at all**: WhatsApp **Templates**, **Campaigns** (builder, CSV broadcast, QR) and **Flows / FlowEditor**. Under the current roadmap they stay on the old skin **indefinitely**, so *"the app is on the new design system"* never becomes true. Probable cause, not oversight: WhatsApp is Meta-disabled, so those screens are dormant and nobody thought about them. **For Fable:** keep the reskin distributed and explicitly assign the orphans, or insert a real UI-sweep phase? The executor's read: the original reason to avoid a sweep was that the tokens were **unproven** — they are not anymore, having shipped on eight Agent screens, and the primitives (`Card`, `Pill`, `Table`, `Field`, `SegmentedControl`, `StatTile`, `EmptyState`) exist. A sweep is now mostly mechanical and fans out well. But the sequencing call is Fable's. ## 6. Where does this work belong? (Phase numbering) The operator asked whether these are beyond Phase 1 and whether to push them to Phase 2. **They are beyond Phase 1 — but they do not belong to Phase 2 either.** The roadmap (target picture §10): | Phase | Purpose | State | |---|---|---| | 0 | Design system via style tiles → the token sheet; plus the code review + LeadRat spike | Done | | **1** | **The Agent, rebuilt** on the tokens (1A/1B traces·Activity·Review·Posts·Triggers; 1C Behaviour·Knowledge·Playground·Model) | **Code-complete, awaiting Gate 1C** | | 2 | **Home + alerting** | Not started | | 3 | **Channel-agnostic sweep** — Connections multi-channel + webhook surface, filters, Segments→Contacts | Not started | | 4 | **Analytics** (the five questions) | Not started | | 5 | **Automation + Reminders** (engine v2) | Not started | Pushing comment moderation into Phase 2 would put it inside *Home + alerting*, which is unrelated. **§1–§4 are a gap in Phase 1's own subject matter — the Agent.** The executor suggested a **Phase 1D**, but the phase numbering is Fable's call, not the executor's. --- ## 7. Operator's additions > *The operator will add items here. Left deliberately open.* ### way everything is planned - the scope of each phase seems independent so why is it considered sequecial? if they are independent, than there is no actual reason not to plan for to avoid guessing. - each phase I feel should be like a gate to continue work of one scope instead of sequecial each phase, because each phase is geniunely a continous working indepedent of each phase and maybe co-dependent sometimes. - the claim that we are not planning all "phases" together because to avoid guessing it really wrong execuse. because of reason of continious work on each phase, we are always working on each phase because its own thing and it feels impossible and not encouraged to leave a phase because its sequencial and can't go back - I always think of functionalities and stuff to improve while using and while not. I don't have everything and all the scope at once. ### a bit of gaps I found on manager myself - Instagram comments section and AI agent activity section seems to do very similiar functions, I understand because the only activity we have right now is comments monitoring, but I still see the activity section more functional than comments section for instagram comments when this shouldn't be the case - there is no way to see the comments of *each post*. All of the comments are simply shown and the only link is the post number that can't intuitively link to a posts. It will be nice to see each post with its thumbnail and I can click to see its posts. ui and mockups should be discussed. like a section in isntagram - the campaign posts/boosted posts from ads manager is not interperted or added in a way. Good thing is that comments webhooks send it. this could be like a section in the posts section where it shows the public/page and the ads posts. - I like the bevaoiure section, but I don't feel its complete in a way. maybe because its not fully customizable, just hardcoded, like the plan didn't explicify it and the executor took it into plain sight. The ui is weird, like there is a side nav aand a top nav and only the top nav has a company tab and there is not implicit hierachy and no customizability. and I still feel that there is not enough transparency and customizability. like the Knowledge section has a lot of modules that is not customiazilible and its quite hidden in knowledge instead of it being in behavoir section which breaks my trust, like what else is hidden or even not shown. the executor failed to acheive the vision compleletly. - there is still ai-ish text sometimes. ### methodology - this makes me thing, what is the problem in the execution? is the executor problem or the planner? or a context and vision problem? - does the execution, envisioning and planners methods neds to be changed? - is everything indexed well? does the executor get enough context and know wherre to look? I see a lot of noise markdown files in plans and docs folder potentially. this is noise that disturb me and might disturb the execution --- ## What the executor did NOT do - Did not build any of the above. - Did not flip `instagram:comments` (it stays shadow; the operator flips it). - Did not root-cause §4's empty completion. - Did not verify ManyChat's API surface (§3) — flagged as unverified rather than assumed.