The Persistent Monitor

1. Status

Design sketch. Not built. Every other paper in this set (1 through 4, 6, and 7) describes mechanism that is actually running in this project today. This one does not, and the difference matters enough that it gets its own status line instead of sharing the "living document" framing the others use. Treat every claim below as a proposal, not a report.

2. Motivation

Papers 1 through 4, 6, and 7 all describe this project's SDLC responding to something that already happened inside the project — a failed check, a stated vision, a concurrent-session collision. None of them describe an inbound channel for something that happened outside it: a new failure mode another team reported, a counterargument to loop-native development worth taking seriously, a practice this project should probably steal. Nothing currently watches for that. This paper sketches what a mechanism for it would look like, without pretending one exists yet.

3. Core Thesis

A persistent monitor would be a daemon — the same shape already proven for an unrelated purpose (the Twitch chat bot's PID-locked singleton daemon, per scripts/twitch/daemon-lock.js) — except it would read instead of connect to a chat socket: it would continuously watch external developer discourse for material relevant to this project's own SDLC stance, and it would surface a proposal for the human to review, never act on one itself. It would belong specifically in the daemon+PID-lock tier of Paper 1 P5's loop taxonomy, because "must stay watching continuously" is that tier's entire reason for existing — not the scheduled-routine tier, which wakes up periodically and goes back to sleep, and not any session-bound tier, which dies when the session does.

4. Design Sketch

Since nothing here is built, this section describes shape and constraints, not shipped practice: - Tier: Daemon + PID-lock (docs/GuidanceForClaudeCode.md §12a; the public gloss is Paper 1 P5), the same tier already validated by the Twitch chat daemon. "Stay connected/watching" rather than "wake up on a schedule" is that tier's fit criterion, and it's this mechanism's fit criterion too. - Own singleton lock: would follow scripts/twitch/daemon-lock.js's existing pattern rather than inventing a new one — verify liveness before starting a second instance, the same requirement this project's one existing long-running daemon (the Twitch chat bot) already has, and that any future daemon should inherit rather than reinvent. - Would never auto-apply anything. This isn't a special carve-out invented for this feature — it's Paper 1 P1 and Paper 3 L5 ("mutation is gated," "gate sits outside the loop's own control") applied to a new daemon instead of relaxed for it. A monitor that could edit this project's own doctrine unattended would be a mutation loop with no gate, which nothing else here is allowed to be either. Its entire output would be a proposal, routed through the same owner-review mechanisms Paper 6 catalogs (AskUserQuestion for a single finding, /architect-action for something that needs tracking across sessions, /architect-action-extended for bulk or visual findings) — never a direct edit. - Kill switch: would carry the same requirement as every other daemon in the taxonomy — verify liveness, SIGTERM, re-verify liveness (never assume a kill worked, ANTI-PATTERNS.md #10). Not a new invention; this tier's existing requirement, would just be inherited here too. - Genuinely undecided, on purpose: what "external industry discourse" means as an actual ingestible source — a fixed reading list, search queries, something else — is not specified here. Speccing it now, before there's a concrete reason to build it, would be inventing scope ahead of need, which this paper is explicitly declining to do.

5. Non-Goals

• This is not built. No daemon exists for this purpose today — same claim as the cold open and §1, listed here only because a Non-Goals section that omitted it would read like an oversight, not because it needs saying a third time.
• Not a ship date or a commitment to build it on any particular timeline.
• Not an exception to Paper 1's mutation-gating principle. Even fully built, it would never apply anything on its own — only propose.
• Not a specification of the ingestion source. That's an open question, deliberately left open.
• Not covered in Workflows, this project's diagram-first SDLC reference — that section deliberately documents only mechanism that actually exists, and an empty drawer doesn't get a diagram just because a design sketch describes its shape.
• Not part of the Perspectivity Research Reports series. An empty labeled drawer isn't a plot device over here; it's just what an unbuilt feature actually looks like when nobody dresses it up first.

6. Revision History