Memory

Project State

Phase: Specification & Design (complete) — one review open before production Ready for: Implementation, with the AI agent review (ADR-018) gating production

Key Counts

Artifact Count
Spec documents 14
UX documents 38 (in reading order)
Wireframe documents 22
Screens 240
Languages 2 (EN, ES) — 52 documents in Spanish
ADRs 21 (001-021; 20 accepted, 018 proposed)
Diary entries 15

Completed Work

  1. Specification — 12 interconnected spec documents covering product, users, workflows, geography, security, compliance, fundraising, integrations, support, GOTV, messaging, press
  2. Architecture — System architecture document with data model, infrastructure, and technical decisions
  3. Information Architecture — Navigation model, screen inventory, persona views, URL structure
  4. Design System — Foundations, theming, components, responsive strategy
  5. Wireframes — 22 documents covering 240 screens across all feature areas
  6. Wireframe Audit — Normalized structure, filled gaps, consolidated open questions
  7. Open Question Resolution — All 89 questions resolved in ADR-016
  8. Architecture Reconciliation — system.md updated to reflect ADR-016 decisions
  9. Housekeeping — Documentation consistency, numbering fixes, README updates
  10. Documentation Website — Custom static-site generator (scripts/build.mjs, Node + markdown-it) renders all Markdown into a browsable site in docs/ with sidebar TOC, search, and dark mode, styled with the project's own design tokens. Deploys to GitHub Pages via .github/workflows/pages.yml. The build caught and fixed 33 broken ../decisions/ links in system.md (should be ../../decisions/).

Key Decisions (from ADR-016)

  • AI Model: BYOM (Bring Your Own Model) — tenants provide their own API keys
  • Data Retention: Tiered policy (operational/compliance/archival)
  • Channel Orchestration: Two layers per tenant (per-channel caps, cross-channel quiet window); ADR-019 adds a third for alliance members, cross-tenant mutual suppression
  • Election Results Security: Multi-layer (Entry → Confirmation → Entry Lock → Canvass)
  • v2 Tentpoles: Visual Flow Builder, Shared Content Library, Settings Delegation, Public Page A/B Testing

File Locations

  • Specs: spec/*.md
  • UX: design/ux/ (see 00-overview.md for reading order)
  • Architecture: design/architecture/system.md
  • Decisions: decisions/001-021.md + ux-decisions.md
  • Diary: diary/01-14.md
  • Spanish: i18n/es/ mirrors the English paths; i18n/GLOSSARY.md is the binding terminology contract
  • Docs site: generated by scripts/build.mjs into docs/; source assets in site-assets/; canonical source stays Markdown

Open Gate: AI Agent Posture (ADR-018, Proposed)

The corpus decided AI five times as bounded features (ADR-010 translation, ADR-013 activism messaging, ADR-014 concierge, ADR-016 §38 BYOM, system.md AI Integration) and never asked what changes if agents operate throughout the product. spec/security.md and ADR-002 contain zero AI references; spec/compliance.md contains one.

decisions/018-ai-agent-posture.md is the project's first Proposed ADR. It gates production — not prototyping — on any capability with cross-feature read scope, tool authority, autonomous action, or broad credentials. The five accepted features are unaffected. Diary entry 12 tells the story; ADR-018 lists the eight things the review must resolve.

Three inconsistencies were recorded in ADR-018. The first (ADR-013 without a supersession banner) was resolved by ADR-019 with a clarifying banner: ADR-013 never made a model decision, so nothing in it is superseded. Two remain deliberately unfixed: dashboards.md still calls reallocation suggestions AI-generated after ADR-016 §49 made them rule-based, and the BYOM settings screen ADR-016 committed to was never drawn.

Recent Session (2026-09-07)

Added diary entry 12 and ADR-018 (EN + ES), amended the phase language in README.md and CLAUDE.md, added 15 agent-vocabulary rows to i18n/GLOSSARY.md, and refreshed this file. The build caught one bad anchor on the way in: #war-room--key-differences-from-other-dashboards has a single hyphen, not a double — the same em-dash collapse that produced the #door-card--canvassing bug in entry 10.

ADR-019: Central Services & Metered Billing (2026-09-28, Accepted)

Every capability is an internal module (runs in the tenant instance, flat subscription) or a central service (platform-hosted, executed per tenant under the tenant's keys and contracts, retains nothing between calls, metered). Third-party variable costs pass through at cost with no margin; GreenGrass earns from the subscription alone. Catalogue, entitlements and metering are platform-layer metadata. An affiliation carries billing_mode (member_pays | alliance_pays), set at onboarding, changed only by both OAs; paying is not seeing. Free-tier metered allowance is deferred. Entitlements are the credential boundary any future agent inherits — ADR-018 is fed, not resolved. Amends ADR-007 (banner added); clarifies ADR-013 (banner added). Diary entry 13.

Planned follow-ups from the same Whimsical board: suppression as first catalogue entry (mvp/workflows/system), the four central services into the comms-intelligence iterations, content ops from the creator wireframes into press.md, then ADR-018 fed with the board as the proposal under review.

Mutual Suppression as the First Central Service (2026-09-28)

PR 2 of the five planned against the ADR-019 board. spec/mvp.md § 2 places the pilot's suppression check in the catalogue; system.md § Cross-channel orchestration engine gains layer 3; workflows.md § 7 adds the step to the email and SMS/WhatsApp flows; users.md lists recent contact as a shareable resource; ADR-016 gets an Amended-by banner for §2.

Three design points were made explicit rather than left implied. The "shared ledger" is each member's own contact history, asked per call, since a central service retains nothing. Matching needs a second blind index keyed per alliance contract, because the tenant-keyed one cannot match across tenants. An unanswered member is not a veto: the send proceeds and the record notes who did not answer. No diary entry: entry 14 is reserved for PR 5.

ADR-020: The Four Central Services & Builders (2026-09-28, Accepted)

PR 3 of five. The board's four services are Capture, Analysis, Builders and channel transport. Capture is comms-intelligence Iteration 3 (sources: published press, transcribed broadcast, public social accounts, published polls; never closed messaging), still gated on the Iteration 0 corpus probe; ADR-015 banner records the move from deferred to specified. Analysis delivers Iterations 5–6 into compartments and adds electoral analysis over published results, which is named but unscheduled (§12 Q7). Builders is a new Iteration 7, off the main line, depending only on Iteration 1.

Builder bounds: invoked by a person with a brief, reads only what it is handed, returns a draft into existing approval workflows, no credential to transport. Text builders are accepted; image and video builders are proposed and cannot be enabled until ADR-018 is accepted with item 6 answered. ADR-016 #25 holds for video editing; generation is a separate, gated capability (banner extended). "Proposed", never "candidate": the word collides with the political candidate in both languages.

ADR-021: Creator Program & Content Pipeline (2026-09-28, Accepted — superseded the same day, see "ADR-021 Narrowed" below)

PR 4 of five, from the Replit prototype at whats-app-manager.replit.app/wireframe-viewer (21 screens: 17 desktop + 4 mobile; commercial sample data). User decision: creators are treated exactly like press contacts and influencers — Contact records with creator fields (tier A–D, tier history, platforms, WhatsApp), any tenant may run a program, and cross-tenant creator relationships need an ADR-017 contract. No creator record type.

The redraw is design/ux/04-wireframes/content-ops/content-ops.md, CONTENT-001–012 (12 screens; 236 → 248). Mobile variants folded into desktop screens; Team & Roles and Notifications map to existing SET-/shell screens; the three AI screens (fit score, analysis, production instructions) and inbound auto-classification are held for ADR-018 (PR 5). Engagement is staff-only and never ranked (ADR-015). WhatsApp inbox respects the 24-hour window; templates outside it. ADR-016 #22 generalized to a content pipeline; #23's versioned assets pulled forward, rest of the library stays v2. New role templates: Editor, Approver, Creator Manager. In-kind contribution question added to press.md open questions. Screens live under the Press nav (/press/creators, /press/content).

ADR-018 Gains the Proposal Under Review (2026-09-28, still Proposed)

PR 5 of five. ADR-018 has a new section, "The proposal under review". Every line in it is a proposal and nothing is accepted. It holds the board's per-tenant agent harness: four sources (strategy, KB, geo, CRM) → agents → people, and every dispatch arrow starts at a person. Proposed answers: item 5 cost (ADR-019 pass-through), credential breadth (a gating property, not an item: entitlements), item 6 first enumerated form "no agent dispatches", item 7 agent reads compartments only under the invoking person's contract, never in the background. Open and central: read scope. The content-ops flow reads one item plus designated docs (the floor); the harness reads four sources (the ceiling). Worked example: the content-ops AI flow, proposed as a bounded feature, "the first evaluated under this review". Deliberately not numbered "sixth", because ADR-020's text builders changed the count. The on-arrival fit badge is flagged as autonomous action, with three options for the review. ADR-020's image/video questions are recorded under item 6. Diary entry 14 closes the loop from entry 12.

ADR-021 Narrowed: Not a Creator Tool (2026-09-28, still Accepted)

User direction, after a diagram built on the creator wireframes: "we're not trying to manage content creators." ADR-021 renamed to 021-content-approval-pipeline.md (Content Approval Pipeline) and narrowed to review in rounds: every round kept, compare rounds, revision requests need a comment, Editor can escalate, final approval by the candidate or an Approver per the Post Approval Workflow, nothing published by a machine, versioned assets forward from v2. Role templates: Editor, Approver (Creator Manager gone). Withdrawn on the record in ADR-021 "What this ADR no longer decides": creators as contacts, tiers, dispatch, tier routing, two-way WhatsApp inbox (integrations.md reverted to pre-ADR-021), per-creator engagement, creator compliance, the prototype's AI screens. content-ops.md is 4 screens (CONTENT-001 Content Dashboard, 002 Content Review, 003 Approval Queue, 004 Approval); 248 → 240 screens. Glossary keeps creator terms in a "retired" table. Do not reintroduce creator rosters, tiers, dispatch or a creator inbox.

ADR-018's worked example is now a candidate approving the day's posts over WhatsApp (from a prototype PDF; drawn on the Whimsical services board): agent reads strategy, KB, calendar; speaks first; generates images; schedules approved pieces; staff change pieces after approval; audit needs an on-behalf-of actor. The central question for item 6: does a tap on Approve count as the person's send? "Approving from WhatsApp without an agent" is an open question in press.md, not decided. Diary entry 15.