← Cycles
Design · c137

App Messaging, Overseer and Citizen

archivedcreated 2026-11-09· last activity 2026-11-13· mode: rebellion → formula.

The ports and bones of every message between the overseer (the control plane and the people who run it) and the citizen (the employee at the endpoint): one schema, the channels (inbox, tray, OS notification, web app), the inventory of message types the roadmap implies, and the citizen's control over what reaches them. Simple, and never a bombardment.

New in this cycle: The message channel's ports and bones

Why

When qcontrol enforces a policy, the person at the keyboard sees a disruption and nothing else. Mark Peterson asked for local feedback with a path to IT. Mark Parson's prompt adds notices from HQ, confirmations of identity, censures, new responsibilities and training. Each is a message, and if each is built where it is needed the person is bombarded on the one surface an employee actually sees. The brand promises "invisible when working, visible when needed" and "we are not noisy"; this cycle is where that promise is designed. Mark ruled on 2026-11-09 that the channel's ports and bones ship in V1 even though only Connect confirmations flow at first.

Overseer, ports, citizenSketch: Overseer, ports, citizen, drawn 2026-11-10 in the design system; Mark's own drawings may replace it.

Objective

Done means: the message inventory with a 5-question pass per type; the schema (the bones) as a document and a types entry in ../qnative; ten example messages in brand voice; the citizen's inbox and controls and the operator's send side mocked and reviewed; the V1 slice (schema, inbox store, OS plumbing, per-type controls, tray count, Connect confirmation) built with c131; the plane side agreed with c134; the training and grant message types handed to c133 and c136.

Scope

  • Cycle docs: cycles/c137.app-messaging/ (plan.md, the inventory, the example messages, thread prompt/plan pairs)
  • Design site: the web side in the phase-4 lab; the native side in c132's medium
  • Sister projects: ../qnative (types, inbox, plumbing), the control-plane repo via c134
  • Out: email and Slack delivery to the citizen (later, through integrations); the product words for the two roles (c0); the content of trainings (c133) and grants (c136)

Key Changes

  • stage 1 (2026-11-09): created from Mark's ruling on c130 D9 during the decisions walk: "ports and bones" in V1, the design as its own cycle, exquisite control for the user. initial-prompt.md quotes his words; plan.md proposes the parties, ports, bones, the type inventory, the citizen's controls, seven rules and eight defaults. CYCLE.md written before kick-off at Mark's request (c130 clarifying question 6).
  • kick-off (2026-11-09): Mark confirmed D1–D8 and started the cycle: Phases 0–2 in their own session (inventory.md, bones.md with ten example messages, ports.md and the lab mocks), review stop after. The types entry for ../qnative waits for c131 Phase 1; the spike owns that repo meanwhile. Committed the same day.
  • Phase 0 (2026-11-09): inventory.md: 24 rows considered, 16 kept (15 distinct types; enforcement-notice from the plane and from qcontrol locally), 8 dropped by the five questions (config-change, the mechanic-access notice to the citizen, the observe-mode nudge, endpoint-connected, reminder, digest, welcome, app-update; three of them survive as rules or port behaviours). Each row carries its source (1b21a3ce, Mark's prompt, c133, c136, c131 Connect, the plan), the default delivery (off · inbox · tray · notify) and whether required may apply (enforcement and censure by default, hq-notice only when the plane allows it; always counted). V1 set: identity-confirmation flows; enforcement notices and contact-it if Tyler rules them in at G2. Four questions raised, with defaults (local mode's IT contact from qcontrol's config; approval planes; the sensor-state threshold; whether the overseer sees seen).
  • Phase 1 (2026-11-09): bones.md: the schema as a specification in the wire shape (fields and types; severities info · attention · required; states new · seen · acknowledged · done · expired with their transitions, terminal states and expires_at defaults; the required rule as the one override, counted per recipient per month with a soft ceiling of three and a reason line above it; the sender label as a plane-set string, default "HQ"; threads, mute keys, the send side for c134; what the plane records under R6). Ten example messages, one per important type, each body in the brand's three sentences, plus two for the operator's inbox; all twelve checked with the brand MCP's check-brand-voice tool, zero violations. No Rust and nothing in ../qnative: the types entry lands with c131 Phase 1.
  • Phase 2 (2026-11-09): ports.md: the four ports (inbox, tray, OS notification, web app; email and Slack out of V1) with the inbox's honesty line, the tray's count and one line, the OS notification per platform and what c131's spike must confirm (required as the OS's break-through level only where the entitlement exists); the citizen's controls (per kind off · inbox · tray · notify with the inventory's defaults, quiet hours in front of the OS's Focus, mutes for a day, the single required override with its monthly count and the plane's soft ceiling, "why am I seeing this" on every card, nothing hidden); the operator's send side for c134 (the inbox with states per recipient and Recall, Send with the three-sentence fields, the required count, the preview and the voice lint; three plane settings; the audit events). Mocked in the phase-4 lab: /pages/phase4/messaging-bones (the one message component over the ten examples and the two operator-side ones across the five states, with the OS notification and the tray line each becomes), /pages/phase4/messaging-inbox (the person's inbox and settings as a web rendering standing in for the native app until c132, the tray and the newest notification beside it, connected and local worlds), /pages/phase4/mock/messages (the operator's side in the lab's qdash shell, not on the rail). One visit state (useMessagingMock): a message sent from the operator's page lands in the person's inbox. Layer components first (UxPageTitle, UxTabGroup, UxFilterGroup, UxPill, UxToggle, UxButton, UxPopover, UxSelect, DataTable); the card, the notification and the tray line are design-local (app/components/messaging/). Registered in page-registry.ts (collapse c137-messaging) and on the phase-4 index. Verified on :3000 with curl and in the browser (no console errors; acknowledge, settings, send and the lint exercised); captured to public/cycles/design/c137-*.png. Ten questions for Mark in ports.md §5. Review stop.
  • sketch and story (2026-11-10): the channel drawn as Overseer, ports, citizen in the design system (the three columns, the four ports, what flows first, the bones, the citizen's controls; captured as c137-sketch-channel.png for the Why and the story's hero), the story module app/data/stories/c137.ts (nine decisions, five outcomes, four shots; pickup: Mark's review of the ten questions, then Phase 3 with c131), and ## The shape above. Nothing in ../qnative.
  • 2026-11-11: the first native tour ruled in c131 (D15; synthetic data §Rulings): switch to priya's world, simulate a bad event, watch the local enforcement notice and tune the controls; it is this cycle's Phase 3 slice seen from the person's chair. Plan: a paragraph under Phase 3 and clarifying question 5 (which arc event the drill injects).
  • 2026-11-11, later: the drill ruled: all three arc events (an egress notice, a sensitive-file notice, the incident's), as one tour or three (question 5 answered); the IT-contact half stays with question 1.
  • 2026-11-11, evening: the ten questions of ports.md §5 walked with Mark and answered there (§Answered); the plan gains D9–D13: three delivery modes per kind (quiet · normal · priority, each an OS interruption level, priority only for required), alert permission asked at Connect, open required and new lifted above seen, the voice lint's strictness a plane setting, a toast after an action, and the six V1 answers (no floor, required without the entitlement, no acknowledge from the notification, one sender label, Admin › Messages, one-way Contact IT in local mode). The lab mock follows in Phase 3. Review stop cleared; Phase 3 waits for c131 Phase 1 in qnative.
  • Phase 3 kicked off (2026-11-11, evening): Mark ruled the V1 slice starts now as qnative cycle c4 in a fresh session (the schema in types, the SQLite inbox, the OS plumbing with the three modes, the tray count, the identity confirmation flowing, a story per state), since c2 had built what c131 Phase 1 planned. The violation tour (c131 D15) follows it.
  • Phase 3 (2026-11-11): started as qnative c4 (../qnative/cycles/c4.messaging/, review stop 1 in its review-1.md). Built in five steps on the pipes c2 made: the bones as types::messages written from bones.md with the ten examples as a fixture and a drift test that reads this file; the SQLite inbox beside the app's settings (D1) with §5's transitions, expiry, the required count and a delivery record per message; the inbox page with the lift (D10), the card with "why am I seeing this", Acknowledge and the toast through the Root's host (D12), the honesty line; the tray's count and one line; the OS notification behind one trait with the macOS port (UNUserNotificationCenter, the interruption level per post from the mode, D9; the time-sensitive entitlement read from the signature, so priority is honest only on a signed build), Windows and Linux saying "not available here"; the Messages settings page (four positions per kind, the tray switch, quiet hours in front of Focus, mutes, the required override and its count, what the build can post, what the app records); messages as a resource of the nozzle (D2: /api/messages, answered by the synthetic world and the fixture plane from the ten) with the inbox syncing from it; the identity confirmation composed and delivered on a plane connect (the V1 flow) and the local enforcement notice delivered by a drill in synthetic worlds. Thirteen captures in the qnative atlas (thread c4-messaging). Findings for the bones: required_reason (§6 needs it, §1 lacks it), Reply (E6 names it, §4 has no kind), the ten speak of Acme and MBP-2291 while the worlds are Meridian's; and the five delivery words of D9 against the inventory's four, for Mark.
  • inbox rename thread (2026-11-13): after the Qpoint Product session f8d58bc9 (2026-11-12: Rob, "another thing to check", the "no changes for end users" promise; Mark, "I don't think it should really be an inbox"; the adopted "how noisy do you want me to be"), Mark asked to rename the section and reword it so a correction never feels like prison (inbox-rename-prompt.md). inbox-rename-plan.md proposes Safety: one noise control (Quietly by default · When it matters · Teach me), two sources in three groups mapped to the finding's outcome (Stopped in time · Noticed · From HQ), the words to retire (censure, enforcement notice, overseer and citizen), voice-checked help text, the audit log's softer stance for prevented moments, and seven calls for Mark, three of them for Mark Peterson. Nothing built. The same day Mark ruled call 1: the section is Safety & Security.
  • reframe and close (2026-11-13, later): Mark: "there is already the notion of findings, should we start by replicating that as a way to note and communicate violations to policy?", a question about the cycle's purpose. Design's phase-4 Findings (c114 → c121 → c133, lab only) already models the prompt's two sources: the outcome Enforced or Observed is before and after, and the Qplane's remediation is events on the finding (plan §10). Mark: findings bubble up to a company plane when connected, trainings bubble down, "so they speak a common tongue". His four answers: close c137 into a new cycle; prevented is softest (revisits c121 D3); all findings bubble up, prevented ones softer; Findings replaces qnative c4's inbox and keeps its plumbing. c147 opened at Stage 1 with his words; c137 closed into it.

Outcome

Closed 2026-11-13 into c147 (Findings, a Common Tongue). The channel was designed and its V1 slice built, then the 2026-11-12 Product session (f8d58bc9) and Mark's own realization the next day showed that the problem never asked for a channel. enforcement-without-local-context asks whether the person can see what qcontrol detected or blocked, why, and how to reach IT: a finding, seen from the machine where it happened.

  • What was made: the inventory (24 rows, 16 kept, 15 types), the bones (one schema, ten voice-checked examples), the ports (four channels and the person's controls), three lab pages, the channel sketch, D1–D13; qnative c4 built the V1 slice (the types, the SQLite inbox, the Inbox and Messages settings pages, the tray count, the macOS OS notification behind one trait, the identity confirmation on Connect, the drill).
  • Why it closes: an inbox is "another thing to check" against the homepage's "no changes for end users" (Rob); "I don't think it should really be an inbox" (Mark); and the notion already exists, as design's findings. The lesson is the methodology's own: c137 ran in rebellion and built the channel before one use proved itself, where assemblage would have started from what existed.
  • Carried into c147: the section's name, Safety & Security; the voice rules and the words to retire (violation, censure, enforcement notice, overseer and citizen); the noise control (Quietly · When it matters · Teach me, from the session's adopted "how noisy do you want me to be"); "why am I seeing this" and nothing hidden; c4's OS notification plumbing, the tray and the noise settings, announcing findings once the Findings view replaces the message store and the Inbox page.
  • Shelved, on file: HQ's letters, censures, responsibilities, diagnostics requests, replies and the operator's Send form with the required count. The session sent HQ's messages to the channels people already have (email, Slack); the identity confirmation is answered by Status saying whether the machine is standalone or connected (f8d58bc9).

The shape

Documents: the plan · Mark's prompt · the inventory · the bones · the ports

Drawn as Overseer, ports, citizen on 2026-11-10; the records behind it are plan.md, inventory.md, bones.md and ports.md.

The problem. When qcontrol enforces a policy, the person at the keyboard sees a disruption and nothing else (Mark Peterson, 1b21a3ce). Mark's prompt adds notices from HQ, confirmations of identity, censures, responsibilities and training. Built where each is needed, they bombard the one surface an employee actually sees, and the brand's "we are not noisy" breaks there.

The core idea. Design the channel once and ship its plumbing in V1 (c130 D9). Two parties: the overseer (the plane and the people who run it; "HQ" as the default sender label) and the citizen (the person at the keyboard; "you" in the UI). One schema for every message. The citizen controls delivery, the overseer controls content; required is the single override, and it is counted in both directions. Nothing is hidden: the inbox says what the settings held back.

The pieces. Four ports: the inbox in the native app (always on), the tray (on · off), the OS notification (per type, with quiet hours; the OS's Focus honoured), the web app (the operator's inbox and Send; c134). The bones: type, severity (info · attention · required), from, to, subject, a three-sentence body, actions, links, why, requires_ack, expires_at, state (new · seen · acknowledged · done · expired), thread. Sixteen rows kept of twenty-four: identity-confirmation flows in V1, enforcement notices and contact-it if Tyler rules them in at G2, the rest later. The citizen's controls: per type off · inbox · tray · notify, quiet hours, mutes for a day, the required count, "why am I seeing this" on every card, the withheld count.

The pattern we follow. A message is a module: its type the purpose, its bones the protocol, its internals free (a censure, a training assignment and a grant notice ride the same shape). The channel is the protocol between two modules: the citizen controls delivery, the overseer controls content. "Exquisite control" is the edge of chaos applied to attention: the overseer's freedom to send meets the citizen's order over what gets through.

What stays open. The ten questions in ports.md §5, for Mark at the review stop: enforcement notices lowered to inbox only; provisional delivery on macOS as the first run; the required entitlement; Acknowledge from the notification; one sender label per plane; the operator's inbox place; local mode's one-way Contact IT; inbox order; the lint advising, never blocking; the toast when a message ends. Beyond them: which messages flow beyond Connect (Tyler, G2 Q12) and the plane side (c134).

Visual record

7 captures — heroes, page slices, and full-page renders. Click to view.

Sketches — the structures, drawn in the design system

2026-11-10· 2 captureslatest
Two parties, four ports between them, one schema for every message, and the citizen's hand on the delivery.
Two parties, four ports between them, one schema for every message, and the citizen's hand on the delivery. open page →
c137 full
open page →

Earlier captures

2026-11-09· 5 captures
c137 hero
c137 hero
c137 hero
c137 full
c137 full

Artifacts

Qpoint Brand Style Guide