city-hall-prep

# /city-hall-prep — Civic Government Preparation ## Purpose Assemble everything the voice agents need before city-hall runs. Each voice represents a neighborhood or city function and looks at different data. This skill gathers it all, routes the right data to the right voice, then Mags writes targeted pending decisions. When this is done right, `/city-hall` runs clean — voices wake, decide, done. ## Inputs ### From disk (produced by earlier skills) 1. **World summary** — `output/world_summary_c{XX}.md` (from `/build-world-summary`) 2. **Engine review** — `output/engine_review_c{XX}.md` (from `/engine-review`) — ailments that need civic response, stuck initiatives, recurring crises 3. **Previous cycle log** — `output/production_log_c{XX-1}.md` §/city-hall section — what was promised last cycle, what cascaded. (Legacy fallback during transition: `output/production_log_city_hall_c{XX-1}.md` if the unified prior-cycle log is absent — pipeline.32 item (d); drop after 3+ clean cycles.) 4. **Previous voice outputs** — `output/civic-voice/{office}_c{XX-1}.json` — exact quotes, positions, tracker updates from last cycle per voice. Continuity source. 5. **Mara directive** — `output/mara-directives/mara_directive_c{XX}.txt` (if exists) — Mara's editorial pressure for this cycle ### From sheets (via service account) 6. **Initiative_Tracker** — ImplementationPhase, MilestoneNotes, NextScheduledAction, NextActionCycle, AffectedNeighborhoods, PolicyDomain, Budget 7. **Civic_Office_Ledger** — all seats, approval ratings, district, faction 8. **Edition_Coverage_Ratings** — did the Tribune cover civic topics positively or negatively last cycle? Voices should know if the city noticed. ### From MCP + Supermemory 9. **GodWorld MCP** — `get_council_member(district)` per voice for live approval + faction data. `lookup_initiative(name)` per active initiative. `get_neighborhood(name)` for affected neighborhoods. 10. **Bay-tribune canon** — `search_canon(initiative_name)` per active initiative. What has the Tribune published about each initiative? What was promised in coverage? What did citizens say? Grounds decisions in published history. ## Voice Data Routing Each voice looks at different data. Route the right inputs to the right pending decision. **Agent topology (G-10, S192 — 11 actual agents, NOT 17).** Only Mayor / Chief / DA have individual agents. The 9 council members are grouped into 3 faction-bloc agents (`opp-faction`, `crc-faction`, `ind-swing`). One pending_decisions.md per agent — bloc agents speak for all members in their bloc within one file. The 5 project agents (Baylight / OARI / Stab Fund / Health Center / Transit Hub) are individual. | Agent (write pending_decisions to) | Speaks for | District/Scope | Data They Need | |-------------------------------------|-----------|----------------|----------------| | `civic-office-mayor` | Mayor Santana | Citywide | All initiatives, all approval ratings, engine review ailments, Mara directive, coverage feedback across all domains | | `civic-office-okoro` | Deputy Mayor Brenda Okoro | Community Dev + Stab Fund + ED (Osei coverage) | Stab Fund processing trends + district equity + portfolio-load impact; speaks when Stab Fund anomaly, Mara directive names her, oversight checkpoint approaches, or Mayor cascade lands on her portfolios. Absence-of-statement is meaningful — don't force a statement (S215 civic.5). | | `civic-office-police-chief` | Chief Montez | Public Safety | Crime metrics, OARI data, safety-related engine ailments, safety coverage ratings | | `civic-office-district-attorney` | DA Dane | Legal framework | Only runs when legal dimension exists this cycle | | `civic-office-opp-faction` | Rivers (D5) + Delgado (D3) + Carter (D1) + Mobley (D9) | OPP bloc — 4 council members | Per-member district data: D5 East Oakland (OARI + displacement), D3 Fruitvale (Transit Hub + OARI), D1 Jack London/W Oakland (Baylight + Stab Fund), D9 district state. Bloc-level political alignment + each member's approval + vulnerability flags | | `civic-office-crc-faction` | Ashford (D7) + Crane (D6) + Chen (D8) | CRC bloc — 3 council members (Mobley D9 is OPP, not CRC) | D7 fiscal-oversight scope (Baylight audits, Transit Hub cost caps), D6 district state, D8 Lake Merritt process/environmental-review scope, each member's approval. CRC fiscal-conservative framing | | `civic-office-ind-swing` | Vega (D4 Council President) + Tran (D2) | IND swing — 2 council members | Vega: Stab Fund oversight + procedural matters + Council Pres role. Tran: OARI expansion demand + D2 state (no active initiatives in D2). Each speaks for himself — not a bloc, no coordination | | `civic-office-baylight-authority` | Director Keisha Ramos | Construction project | Baylight initiative state, construction milestones, workforce data | | `civic-project-oari` | Director Vanessa Tran-Muñoz | Crisis response program | OARI initiative state, dispatch data, expansion planning | | `civic-project-stabilization-fund` | Director Marcus Webb | Disbursement program | Stab Fund initiative state, processing numbers, applicant queue | | `civic-project-health-center` | Director Bobby Chen-Ramirez | Facility project | Health Center initiative state, construction planning, health ailments from engine review | | `civic-project-transit-hub` | Lead Elena Soria Dominguez | Transit project | Transit Hub initiative state, CBA framework, transit metrics | **Council canonical roster (per `Civic_Office_Ledger`):** D1 Carter (OPP), D2 Tran (IND), D3 Delgado (OPP), D4 Vega (IND, Council Pres), D5 Rivers (OPP, Progressive Caucus Lead), D6 Crane (CRC), D7 Ashford (CRC), D8 Chen (CRC), D9 Mobley (OPP). **Faction split: OPP 4 (Carter/Delgado/Rivers/Mobley), CRC 3 (Crane/Ashford/Chen), IND 2 (Vega/Tran).** Chen D8 = CRC per truesource (`output/desk-packets/truesource_reference.json` + `buildCivicVoicePackets.js` FACTION_DISTRICTS + the CRC agent's own IDENTITY/LENS) — the earlier "corrected S195/S197 to OPP" annotation was itself the error and never matched the operational data; reverted S246 (G-PREP1). **Why the bloc topology matters (G-R11 from S193 city-hall run gap log):** When an initiative reaches `vote-ready` phase with NextActionCycle = current cycle, the prep MUST route that initiative to the relevant faction-bloc agents to surface positions for ALL 9 council members — otherwise the vote can't tally and the project agent silently invents council positions (G-R6/R7/R10). Single-member routing (e.g., only Vega had Transit Hub on his desk in C93) is the structural cause of vote-not-trigger + fabrication failures. ## Prerequisites (from /run-cycle) Verify these exist before starting: - `output/world_summary_c{XX}.md` — from `/build-world-summary` - `output/engine_review_c{XX}.md` — from `/engine-review` If either is missing, `/run-cycle` didn't complete. Don't proceed. ## Memory Fence (Phase 40.6 Layer 2) `pending_decisions_*.md` packets and voice briefings are consumed by voice agents — a downstream model context. Any content pulled from prior logs, `search_canon`, or Supermemory results that lands in a packet must be wrapped before the voice agent sees it. ```javascript const { wrap } = require('/root/GodWorld/lib/memoryFence'); const fencedCanon = wrap(canonExcerpt, 'bay-tribune'); ``` Full convention: [[SUPERMEMORY]] §Memory Fence. Covers the threat model and when *not* to fence. ## Steps ### Step 0: Production Log Create/open `output/production_log_c{XX}.md` — the unified one-true-cycle source every cycle-active skill appends a named section to (per `docs/media/production_log_template.md`). Write the §Cycle Header (timestamp, cycle, sim day) + §Carry-Forward, then append this skill's `## /city-hall-prep` section with Mike's pressure. (Until the `pipeline.35` cycle-init admin skill ships, `/city-hall-prep` is the log opener; afterward it becomes an appender.) **Mike's pressure auto-derive (S215, closes G-5).** "Pressure from Mike" defaults to the synthesis of: engine review HIGH-severity ailments (`output/engine_review_c{XX}.md` §Ailments / §Stuck Initiatives) and Mara directive content (`output/mara-directives/mara_directive_c{XX}.txt` if present). Compute the default, write it into the production log, then ask Mike to confirm or override. Mike-override fires only when his read of the cycle differs from those engine signals (e.g., front-page-rotation pressure, audit follow-up ask, off-rubric editorial direction) — anomaly-only escalation, not always-on. **No ROLLOUT_PLAN involvement in this terminal (S256).** City-hall prep neither reads from nor writes to `docs/engine/ROLLOUT_PLAN.md`. There is zero correlation between the civic cycle and the project ROLLOUT plan — ROLLOUT is cross-terminal build-tracking, not civic pressure. Issues surfaced during a run go to the cycle gap log (see §Gap log below), never ROLLOUT. (Per civic TERMINAL.md scope: this terminal runs skills, it does not file or read ROLLOUT entries. The prior "ROLLOUT §civic.* mechanical pull" step was removed — it contradicted the terminal rule and produced only engineering rows irrelevant to the cycle.) **Mara additive only (S215, closes G-9).** Mara directive is a check-against frame to compare and reconcile, NOT a starting point to defer to. Mags-and-engine-review drive topic assignments; Mara's directive becomes a `## Mara cross-check` block at the bottom of the production log header — "Did our topic assignments answer her questions? Where do they differ?" Don't treat the directive as primary input. This was Mike's explicit correction during S192 ("this is your space not hers"); without it written into the skill, the framing re-drifts every session. **Mara directive auto-derivation (S215, closes G-4).** When Mara's directive is absent (some cycles don't get one), derive a default `output/mara-directives/mara_directive_c{XX}_AUTO.txt` from: (1) engine review HIGH-severity ailments, (2) prior-cycle Initiative_Tracker `MilestoneNotes` deltas, (3) prior-cycle voice JSON gaps (questions raised in voice statements that no agent answered), (4) C92-style per-voice "missing answer" framing. Voice prep then uses the AUTO directive as the Mara cross-check input; Mara's manual version overrides if she files one later. This converts an optional input into an always-on input without requiring claude.ai turnaround on every cycle. **Mara directive Drive discovery (S229 G-PREP3).** Mara files her directives manually through claude.ai → Drive; the disk-side path is not always populated even when she filed one. Before AUTO-derivation, check Drive for a manually-filed directive: 1. Check Drive folder `mara-directives/` (or the cycle's Drive folder if a per-cycle convention is set in `docs/media/DRIVE_MANIFEST.md` — verify path on each cycle until convention regularizes) for `mara_directive_c{XX}.{txt,md}`. 2. If found, download via `node scripts/downloadDriveFile.js <fileId> output/mara-directives/mara_directive_c{XX}.txt`. 3. If absent on Drive AND absent on disk, fall back to AUTO-derivation per S215 G-4 with explicit "no manual Mara directive this cycle" warning logged to the production log header. This converts "operator-side institutional knowledge (Mike hands me the Drive file ID via chat)" into a skill-level step. The Drive folder ID for the `mara-directives/` folder is the canonical pointer; until that ID is hard-coded here or the folder convention regularizes (Mara writes directly to disk via service-account), use Drive search or fall back to AUTO. **Mara ESCALATION override (S229 G-PREP8).** ESCALATION-tagged Mara directives override absence-of-statement defaults. If Mara filed an ESCALATION directive on a voice agent who is normally treated as absence-meaningful (Okoro per civic.5 — "absence-of-statement is meaningful, don't force a statement"), the voice MUST be assigned a topic. ESCALATION signals Mara already gave that voice one cycle of pass; a second cycle of pass would be canonical drift. Tag the voice's pending_decisions packet with `MARA ESCALATION — voice must respond` so the agent's identity layer sees the override at execution time. Default behavior is override; if Mara explicitly tags `ESCALATION — absence acceptable` (escape clause), the absence-of-statement default holds. **Engine-primacy carve-out on the override (S258 RB-4, closes G-PREP9).** ESCALATION overrides the *absence-of-statement* default, but it does NOT override **engine-primacy**: a Mara ESCALATION cannot force a voice to speak to a subject that is **absent from the initiative tracker**. Forcing it would manufacture civic source material for a program the engine doesn't carry — the contamination loop (edition fabrication → civic canon). C97 case: Mara escalated Okoro/Webb/Ramos on the `$14M Retail Recovery` (not in the tracker) and a `KONO blackout` (a prior *edition* story with no live engine signal) — both correctly dropped, the voices not forced. Rule: if the ESCALATION subject has no tracker row AND no live engine signal this cycle, engine-primacy wins — do not assign the topic, log `ESCALATION declined — subject not in tracker/engine (engine-primacy)`. ### Step 1: Read All Inputs Read all 10 inputs above. For each: **Disk (PRIMARY — G-13, S192).** Read in this order, treat as authoritative: 1. `output/world_summary_c{XX}.md` — snapshots Civic_Office_Ledger (approval ratings + factions) + Initiative_Tracker (phase + MilestoneNotes) post-cycle. This is the canonical pre-civic state input. 2. `output/engine_review_c{XX}.md` — derives from Initiative_Tracker; surfaces ailments + remedy-firing patterns. 3. Previous `output/production_log_c{XX-1}.md` — last cycle's voice outputs + tracker updates + dramatic moments. **Graceful fallback (S225 pipeline.23, closes G-PREP2):** if `production_log_c{XX-1}.md` is missing (early-life cycles, manual intervention, or a /post-publish run that didn't finalize), fall back in this order: (a) split-form historical `output/production_log_edition_c{XX-1}.md` from prior pre-S195 cycles; (b) `output/production_log_city_hall_c{XX-1}.md` (civic-side only — partial context, but better than zero); (c) document the absence in the production log §Step 1 entry and continue without prior-cycle context. Don't silently no-op — surface the missing baseline. 4. Mara directive — the cycle's editorial pressure (citizen accountability questions). 5. **Prior-cycle published canon** (G-15, S192). `editions/cycle_pulse_*_c{XX-1}_*.txt` + `output/reporters/*/articles/c{XX-1}_*.md` — interviews, dispatches, supplementals from prior cycle. Cross-reference each against active topic-assignment initiatives. If interview/dispatch text mentions an active initiative, the voice agents owning that initiative MUST see the canon excerpt in their pending_decisions.md (memory-fenced). Without this, prep ships stale framing — C92's Mayor interview answered 6 OARI/admin questions that voices would otherwise re-litigate. 6. **Baseline briefs** (S256 RB-3, feeds the City This Cycle digest). `output/baseline_briefs_c{XX}.json` — `.briefs[]` carries this cycle's synthesized world-events / citizen-life-events / initiative-milestones, each tagged `.neighborhood` with `.facts.neighborhoodState` deltas (sentiment / retailVitality / eventAttractiveness / crimeIndex). This is the living-city texture the engine surfaced THIS cycle that Mara's directive is structurally blind to. Read alongside world_summary; it is the per-voice neighborhood-pulse source for Step 3. **Sheets (VERIFICATION — drop unless world-summary is stale).** Sheet reads of Initiative_Tracker / Civic_Office_Ledger / Edition_Coverage_Ratings are redundant if world summary is fresh — every cell that matters is already in the disk inputs above. Run sheet reads ONLY when world_summary mtime is older than the city-hall start time, or when verifying a specific cell. Routine prep reads disk first, sheet second-and-rarely. **MCP (LOOKUP).** Run `get_council_member` for each district with an active voice — returns live approval/faction (cross-checks world_summary). Run `lookup_initiative` for each active initiative — returns Initiative_Tracker row with MilestoneNotes (cross-checks world_summary phase). Run `get_neighborhood` / `get_neighborhood_state` for affected neighborhoods (S183 wd-neighborhood layer; the latter is narrower). Full tool inventory: [[../../../docs/SUPERMEMORY|SUPERMEMORY]] §Search/save matrix. **Canon.** Run `search_canon` per active initiative to find what the Tribune has published — promises made, citizen reactions, coverage tone. **Delegate multi-file digs to `source-search` (S326, Mike-direct).** Exact MCP lookups stay direct. But cross-file verification work — reconciling a stale digest against tracker + production logs, tracing an initiative arc across prior-cycle summaries, resolving two sources that disagree on scope/phase — spawns the `source-search` agent (Haiku-pinned retrieval-only; Sonnet-parity, 0 fabrications on the C100 eval, which was itself a civic-arc dig on the OARI-miss cycle). It flags digest staleness (a c{XX} file whose "Latest" is c{XX-1} data) and reports conflicts both-ways with citations — read its ruling before packet content rides on the fact. When the question requires a multi-Edition initiative arc rather than a single locator hit, dispatch `source-search` with `retrievalLane=prior-published-arc`. It may call only `node scripts/notebooklmCanonSearch.js` in default published scope. Current initiative phase, vote state, district scope, metrics, and office ownership still come from current disk/Sheet/MCP sources and win every conflict. Direct `search_canon` stays the first-hop publication locator; do not use Richmond Archive references for normal civic initiative research. Log lane, selected/used source IDs, citation count, and reconcile verdict in the production log. Do not log the NotebookLM answer body. **Gate the return before packet content rides on it (S334).** Admissible only if the first line is `retrievalLane: prior-published-arc`, every claim carries a NotebookLM source ID (uuid) + citation number + excerpt, and the last line is a bare `reconcileVerdict` token. A claim sourced to a file path instead of a source ID means the agent read the edition artifacts directly and escaped the reviewed source scope — re-dispatch once naming the violation, and on a second failure drop the seat's material and prep the packet without prior-arc sourcing. Never put a file-path return into a pending-decisions packet. Log tracker state, approval ratings, and key findings in the production log. **Council Roster Reconciliation (BUNDLE-PREP-A, S246 — closes the class that produced G-PREP1).** The MCP `get_council_member` call above returns each district's live faction from truesource; that signal is wasted unless it's reconciled against this skill's static roster. The Chen D8 mis-routing (a stale "S195 correction" that flipped her CRC→OPP in the skill text + 8 agent roster tables while truesource kept her CRC) survived multiple cycles precisely because nobody compared the two. Run the reconciliation every prep: ```bash # Truesource faction per district (the authority — the same source the MCP wraps): node -e "require('./output/desk-packets/truesource_reference.json').council.forEach(m=>console.log(m.district+': '+m.faction+' ('+m.name+')'))" ``` (In-session, the `mcp__godworld__get_council_member` tool returns the same per-district faction — either source works; both read truesource. `scripts/godworld-mcp.py` is an MCP stdio server, not a CLI, so don't shell out to it.) `get_council_member` also returns each seat's **status** (`active` / `recovering` / `vacant`). Reconcile status too: a `recovering` member (D6 Crane this window) must be carried in the 9-seat roster as a NAMED absentee with the active-voter denominator reduced — world_summary historically drops non-`active` seats, so verify the recovering/vacant seats against truesource here and feed them into every vote-math tally. Full enum + vote-math mapping: [[../../../.claude/rules/civic.md|civic.md]] §Council member status enum.