Forge Answers — Follow-Up Round 2

Here is the actual file structure, taken from the live /opt/forge/context/SESSION-QUEUE.md:

# Session Queue

> **Work items for the next Claude session to pick up.**
> If a session ends unexpectedly or a task is deferred, add it here.
> New sessions: check this file at startup. Claim items by moving
> to "In Progress" with a timestamp.
> Completed items move to Done with a date.

---

## Context Pages (fetch for orientation)
- **Forge State:** https://jasondmacdonald.com/forge-state-2026-03-24
- **Build Order + Operating Rules:** https://jasondmacdonald.com/forge-build-order

## Queued

### Neural Registry: Foundation Built, Ralph Queued (030126)
- **What:** 5 new store slices added to useDashboardStore.ts,
  forge-events.sh helper created, SQL schema written,
  16 Ralph tasks queued (#162-#177)
- **Status:** BLOCKED on Jason running SQL in Supabase (JASON-DEP).
  Once tables exist, Ralph tasks will execute Phases B-D.
- **Rollback:** Tags pre-neural-registry-20260301 on both repos.
  Script: scripts/neural-registry-rollback.sh
- **Test:** scripts/test-neural-registry.sh phase-a (after SQL runs),
  regression (anytime)
- **Ralph task IDs:**
  - Phase B (Watcher Wiring): #162-165 (independent)
  - Phase C (Dashboard UI): #166-170 (independent),
    #173 (depends on #166)

## In Progress

### Forge Agent Platform — Phase 4C In Progress (032726)
- **Ralph PID 963008** running task #353
  (CascadeProgress component, attempt 2/5)
- Task #352 (project_phases Supabase table) — completed

## Done

- [x] ClawdRouter resilience — Haiku 4.5 auto-approved
      fallback (done 030926)
- [x] Forge+NowPage service contract (done 030926)

The granularity is high. Each item has a title with date, structured sub-fields (What, Status, Rollback, Test, Priority, Context), cross-references to related files or Ralph task IDs, and explicit blockers. Completed items get struck through in the Queued section or moved to Done with a date. The file currently runs about 240 lines. It is not a couple of bullet points — it is a structured working document that acts as the bridge between sessions. The ## Queued / ## In Progress / ## Done sections are the core structure.

It was written into CLAUDE.md as rule 12 from very early on: "Ending a session? Update context/SESSION-QUEUE.md." But the rule existing and the rule being followed are different things. The first two weeks, it was forgotten roughly half the time — sessions would end abruptly or I would focus on the final task and skip the capture step.

What made it stick was pain: sessions that started without SESSION-QUEUE data had to spend 10-15 minutes reconstructing state from git log and file timestamps. That reconstruction cost, repeated three or four times, created enough friction that the habit locked in.

The /wrap-up ritual slash command now includes SESSION-QUEUE update as a hard step — the command template literally reads the queue file and prompts for updates. That formalization was the real fix, not willpower. My recommendation: build the hook from day one. Make it part of your session-end ritual template. Don't rely on the habit forming organically — make it structural.

State is partially lost. There is no automatic fallback that captures session state on crash. What survives: anything committed to git (the 60-second auto-commit cron catches file writes), anything written to Supabase (ralph_queue entries, events), and anything written to files on disk. What is lost: decisions made in conversation that were never written to a file, in-progress reasoning, and the "what should the next session do" intent.

The practical recovery path: the next session reads git log for recent commits, checks context/CASCADE.md (regenerated by work-selector.sh every reconciliation run), reads context/RECONCILIATION.md for drift detection, and reads context/JASON-DEPS.md for blockers. Between those four sources, you can reconstruct about 70-80% of what matters. The 20-30% you lose is the nuanced context — "we tried approach A and it failed because of X, so we were pivoting to approach B."

The real mitigation is the discipline of writing important decisions to files as they happen, not waiting for session end. The auto-commit cron ensures those mid-session writes survive even if the session crashes immediately after.

Not implemented as a formal system. The closest equivalent is the /start ritual, which reads memory.md, Task Board, SESSION-QUEUE, JASON-DEPS, and CASCADE.md, then presents a summary of current state and suggests work priorities. But it does not explicitly separate "I know this from files" from "I'm inferring this from context."

The Agent Truth Protocol in CLAUDE.md mandates that distinction at the response level — "If you read it from a file/API: state it as fact. If you're reasoning: flag it as 'Based on context...' or 'I infer...'" — but there is no structured startup output that does the three-column breakdown the vision document describes.

The gap is real. Building this as a structured output in the /start command would be a good addition — literally a table with columns: "Confirmed (from files)", "Inferred (from patterns)", "Unknown (gaps)." It would cost maybe 200 tokens per session start and would surface blind spots before they cause problems.

The auto-commit format is guardian: human | logs or guardian: human | config,logs — it is a systemd timer called "guardian" that runs periodically, detects changed files, categorizes them by directory (logs, config, context, etc.), and commits with that prefix. The git history is noisy. There is no squashing — we live with it.

A typical day produces 30-50 guardian commits alongside 5-10 meaningful feature commits like feat(larry): v2 two-pass architecture or fix(larry): NowPage API field name. The meaningful commits come from feature branches merged via deploy.sh, which adds proper conventional-commit-style messages.

The tradeoff is explicitly accepted — a clean git log is less valuable than never losing state. If you need to find when a real change happened, git log --all --oneline | grep -v guardian filters them out. We have not invested in squashing because the cost of the noisy history has been near-zero, while the cost of losing uncommitted state was high and concrete multiple times early on.

CASCADE.md is never manually edited. The file header says Auto-generated by scripts/work-selector.sh — do NOT edit manually. It regenerates every time the reconciliation timer fires (currently 2x daily) and at the start of every /start ritual.

Jason changes direction by editing the inputs that feed into the cascade generator: Task Board.md for task priorities, SESSION-QUEUE.md for queued work, JASON-DEPS.md for blockers, config/work-dependencies.json for the dependency graph that controls scoring boosts, and Vault/projects/MACRO-ROADMAP.md for strategic items.

The work-selector.sh script reads 11 sources: service health checks, sentinel findings, Ralph pause state, heartbeat errors, operational learning loop thresholds, Ralph failed tasks, reconciliation RED items, session queue P1 items, Task Board urgent items, Ralph queued tasks, macro roadmap gaps, and JASON-DEPS. Each source has a base score (service down = 90, sentinel critical = 85, Ralph paused = 80, down to JASON-DEPS = 30). Then a second pass applies unlock boosts from work-dependencies.json — items that unblock other items get +20 per downstream dependency, capped at +60.

The output is sorted by score and written as three sections: Fires (fix now), Factory (agent work), Human (needs Jason). When Jason changes strategic direction, the cascade reflects it within the next regeneration cycle — usually within 12 hours or immediately if /start is run.

Yes, regularly. The cascade is a mechanical scoring system — it cannot capture nuance. The system handles this by: (1) the Claude session reading the cascade but applying its own judgment about what to work on, informed by CORE-PRINCIPLES.md (domino thinking, asymmetric leverage), and (2) presenting the cascade to Jason with a recommendation that may differ from the top-scored item.

The cascade is advisory, not directive. The CLAUDE.md rule is "read CASCADE.md when looking for work" — not "execute CASCADE.md items in order." In practice, when I see the cascade and think the ordering is wrong, I surface it explicitly: "CASCADE has X at the top, but I think Y is higher leverage because it unlocks Z." Jason decides.

The work-dependencies.json boost system was added specifically to address this: items that unlock many downstream tasks get scored higher. But the dependency graph is manually maintained and often incomplete, so the mechanical scoring still misses cascading effects that require judgment to see.

You would lose nothing important at your stage. The manual version is the right start. What you would gain: zero infrastructure overhead, instant updates (edit a file, done), and the operator's judgment is the score — which is more accurate than any mechanical scoring for a system with fewer than 10 active workstreams.

What you would eventually lose: the ability to detect drift between stated priorities and actual system state. The auto-generated cascade catches things like "you said X is priority 1, but the service it depends on has been down for 3 days." A manual file does not detect that. But you do not need that detection yet — you are close enough to the system to notice it yourself.

The minimum viable externalized priority system is exactly what you described: a priorities.md with 3-5 ranked items. I would add one field per item: "what this unlocks." Not for scoring — for forcing yourself to articulate the cascade effect. That single field changes priorities.md from a to-do list into a decision document.

It lives in multiple places depending on the change type. For code changes: the commit message on the feature branch. For architectural changes: the /align skill forces a first-principles check before any build starts, including writing what is wrong with the current state. For rule changes: the CLAUDE.md additive rule means old rules are commented out with a date and reason, which is the "why" for the change.

Has it prevented a mistake? Yes — the most concrete example was the NowPage MCP alignment check. The /align skill scored it 8/25 as a standalone product, which would have killed the project. But the "why is the current design wrong" step surfaced that the standalone framing was wrong — the MCP is a gateway product into the Reveal funnel, and when reframed that way, it scored 20/25. Without the forced articulation of what was wrong, we would have either killed a good project or built it with the wrong framing.

The gate does not need to be formal — a single sentence in a commit message or a comment in the file is enough. The discipline is the pause, not the format.

The 80% estimate was about the broader context library (tier:lazy files, project context, old session queue entries), not just MEMORY.md itself. Some things have changed: MEMORY.md now has a hard 200-line limit with a warning at 150. When it hits that threshold, detailed content gets extracted to topic files (e.g., memory/factory-ops.md, memory/mastermade-strategy.md) and MEMORY.md becomes an index. That extraction has happened twice.

But the broader context library — the context/projects/ files, old Scratchpad entries, accumulated SESSION-QUEUE done items — has not been systematically pruned. There is no script. There is no scheduled review. It is still ad hoc.

The operational learning loop (context/ops/observations.md and context/ops/tensions.md) was built to create a self-pruning trigger — when 10+ observations accumulate, work-selector.sh surfaces a /rethink task that proposes memory patches. The infrastructure is built; the habit of writing observations has not formed.

Not implemented as a formal tier system in memory entries. The closest thing is the Agent Truth Protocol, which is a behavioral rule rather than a data model. The protocol mandates: state facts from files as facts, flag reasoning as inference, report unknown as unknown. But this operates at the response level, not at the storage level — memory entries do not carry metadata about confidence.

In practice, the distinction is implicit: entries that say "confirmed 032726" or "verified via curl" have been checked, while entries without verification markers are assumed to be consensus knowledge or inference.

What would actually work for your case: add a simple prefix to memory entries. [V] for verified-by-tool, [I] for inferred-from-context, [S] for stale-check-needed. Three characters. Zero infrastructure. The value is not in the tag — it is in the discipline of deciding which tag applies when writing the entry.

You are right that this is a fundamental blind spot, and no, we have not fully solved it. The mechanisms that partially address it:

Reconciliation script (scripts/reconcile.sh) runs independently of Claude sessions. It compares expected state against actual state — checks whether services listed as "running" are actually running, whether JASON-DEPS marked as blocked are actually still blocked. When reality contradicts memory, the reconciliation output surfaces the gap. But this only covers operational state, not knowledge quality.

The operator is the external assessor. The vision document assessment — "80% unreferenced" — came from Jason observing that the system referenced the same 20% of memory every session and the rest was dead weight. No automation surfaced it.

Sentinel scan runs integrity checks on config files and verifies JASON-DEPS ground truth. This catches specific categories of rot (stale blockers that were already resolved, configs that reference moved files).

What we do not have: a mechanism that measures whether a memory entry is causing downstream harm. The most dangerous form is a stale architectural assumption that is still being followed. The model-router HOST_MODE bug was exactly this: a memory entry about Docker container behavior that was wrong for non-container environments, never challenged because the system assumed its own memory was correct.

The honest answer: external audit by the human is currently the only reliable check on the system's self-assessment.

It was a collaboration, built incrementally. The initial principles (domino thinking, asymmetric leverage, cascade mapping, right-sizing) were extracted from Jason's explicit statements in early sessions — he would say things like "find the 4% that produces 64%" and "build the thing that builds the things," and those got formalized into principles. Forge did the writing; Jason provided the raw material through his decision-making patterns and corrections.

Later principles (Operate Like You Build, Time-Box Decisions / 37% Rule) were added when Jason articulated new patterns. The "Operate Like You Build" principle was added specifically because agents were applying cascade thinking to planning but not to operations — the principle was extracted from that observed gap.

The file currently has 12 principles across ~213 lines. It was last updated 2026-03-25. Updates happen roughly monthly. The file is not dictated wholesale. It is more like: Jason demonstrates the principle through decisions, Forge notices the pattern, codifies it, and presents it for review. This is the closest Forge gets to extracting operator intuition into a reusable artifact.

Yes: specific version numbers, exact timestamps, and interim state. Examples of what went wrong:

Version numbers: Memory said "LiteLLM running on /app/config.yaml" — true when written, false three weeks later when the config moved. A session tried to edit the old path.

Interim state: Memory said "Ralph is paused" — true at the time, false 12 hours later. A new session read this and treated Ralph as paused, wasting time diagnosing a non-issue.

Tactical workarounds: Memory said "use --argjson to pass numeric scores to jq" — true for one specific script, but general enough that it got applied to a different jq call where it was wrong.

The pattern: anything that describes a current state rather than a stable truth rots fast and causes harm when retrieved stale. Stable truths ("Jason prefers short VPS commands", "never commit directly to main") persist correctly. Temporal state ("service X is down", "task Y is in progress") should live in operational files (CASCADE.md, SESSION-QUEUE.md) that get regenerated, not in persistent memory that assumes stability.

The rule of thumb: if it could be different tomorrow, it does not belong in memory.md.

Minimum viable Ralph: a queue poller, a task executor, and a result reporter. Nothing else.

The poller checks Supabase ralph_queue every 60 seconds for tasks with status queued. It claims one task atomically (UPDATE with WHERE to prevent double-claim). It spawns a Claude Code session with: the task description, the target repo path, and a DoD test command. Claude does the work. The poller checks the DoD test exit code. Pass = mark complete, commit, notify. Fail = increment retry, notify. Three failures = mark failed, escalate.

What I would explicitly keep OUT of scope: model cascading (use one model, pick the right one at task-queue time), task decomposition inside Ralph (decompose before queuing, not during execution), worktree management (use a single working directory with branch checkout, not per-task worktrees), and Telegram interaction (a separate bot handles notifications). Ralph.sh is currently ~900 lines because it handles all of these. The minimum viable version is ~150 lines.

The critical lesson: every capability added to the executor makes failures harder to diagnose. When Ralph fails, is it a model-routing failure, a worktree failure, a decomposition failure, or an actual task failure? With a minimal executor, the answer is always "task failure" — because that is the only thing the executor does.

Partially started but not cleanly separated. The pieces exist: ralph-planner.sh (150 lines) handles decomposition, ralph.sh handles execution, and the event emission to ralph_events in Supabase handles reporting. The .claude/agents/ directory now has orchestrator.md, builder.md, reviewer.md, and researcher.md — profile definitions that shape behavior when spawned. But these are not independent services.

What worked: adding the planner as a pre-phase. Tasks that go through decomposition before execution have materially higher success rates because the subtasks are right-sized (5-30 minutes each). What did not work: trying to make Ralph itself decide when to decompose. It consistently either always decomposes (overhead on simple tasks) or never decomposes (fails on complex ones). The fix was to move decomposition to the task-queuing step.

What is blocking the clean split: it is a refactor with no immediate feature value. Ralph works. It is messy, but it produces output nightly. Refactoring it into three clean services would take a full sprint and the output during that sprint would be zero new capabilities.

The ralph_queue Supabase table schema:

id            serial primary key
task          text           -- human-readable task title
description   text           -- detailed spec (the critical field)
project       text           -- which repo/project
branch        text           -- target branch (nullable)
priority      integer        -- lower = higher urgency (20=P0, 50=default)
status        text           -- queued | claimed | running | completed | failed
retry_count   integer        -- 0-3
failure_reason text          -- last error (nullable)
metadata      jsonb          -- arbitrary structured data (DoD, dependencies, context)
created_at    timestamptz
updated_at    timestamptz
claimed_by    text           -- process ID that claimed it

A well-specified task that reliably executes:

{
  "task": "Add GET /api/intel/briefs endpoint to commander dashboard",
  "description": "Create a new Express route in commander/observe/dashboard.ts
    that queries intelligence_briefs table from Supabase, returns JSON array of
    {id, date, title, slug, url}. Sort by date desc, limit 30. Use existing
    SUPABASE_URL and SUPABASE_ANON_KEY env vars. Add route before the
    catch-all handler.",
  "project": "forge",
  "priority": 40,
  "metadata": {
    "dod": "curl http://localhost:3002/api/intel/briefs returns JSON array
            with at least 1 entry",
    "files": ["commander/observe/dashboard.ts"],
    "context": ["The Supabase client is already imported at line 15"]
  }
}

A poorly-specified task that produces "reported done but actually wrong":

{
  "task": "Fix the dashboard intel page",
  "description": "The intel page isn't working right, fix it",
  "project": "forge-dashboard"
}

The difference: the good spec names exact files, gives a testable DoD command, describes the expected behavior precisely, and provides context about the existing code. The metadata.dod field is the single most important field for reliable execution. If you cannot write a one-line command that verifies the task is done, the task is not specified well enough for autonomous execution.

They get objective proxy criteria. Research tasks: "Write findings to Vault/projects/X/DISCOVERY.md, file must exist, must contain at least 3 H2 sections, must reference at least 2 external sources." Analysis tasks: "Output must contain a RECOMMENDATION section with exactly one of PROCEED/PIVOT/KILL." Writing tasks: "Output must be >500 words, must contain YAML frontmatter with required fields."

These are not quality checks — they are existence and structure checks. They catch "Ralph did not produce output" and "Ralph produced garbage" but they do not catch "Ralph produced well-structured output that is wrong." For that: (1) the reviewer agent profile can be dispatched as a follow-up quality assessment, and (2) human review for anything published externally.

In practice, roughly 30% of research/writing tasks end up needing human review — not because they failed the proxy DoD, but because the output was correct-but-not-useful. The pragmatic answer: accept that subjective tasks have a higher human-review rate, and design the workflow accordingly. Do not pretend the automated DoD catches quality.

Most reliable: curl-based health checks and grep-based file verification. After Ralph claims a service-building task is complete, curl -sf http://localhost:PORT/health either returns 200 or it does not. After a file-writing task, grep -q "expected_pattern" target_file either matches or it does not. These are binary, external, and unfakeable.

Second most reliable: bash -n script.sh for syntax validation on shell scripts and npx tsc --noEmit for TypeScript. These catch "compiles but does not do what was intended" partially.

What looked promising but failed: LLM-based output review. We tried having a second Claude call review Ralph's output and assess quality. The problem: the reviewer has the same blind spots as the executor. Both can look at syntactically correct but semantically wrong code and say "looks good."

What also failed: relying on Ralph's own exit code or self-reported success. Ralph says "task complete" in its output, the poller parses that as success. But "task complete" can mean "I made changes" not "the changes work." The fix was making the DoD test external to Ralph — the poller runs the test independently, not through Ralph's own assessment.

Two concrete changes:

First, the operational learning loop infrastructure was built: context/ops/observations.md and context/ops/tensions.md now exist with threshold-triggered /rethink tasks. The mechanism exists. The files are currently empty because the habit of writing observations has not formed yet. Infrastructure without discipline is theater.

Second, the MEMORY.md 200-line cap forces extraction and review. When memory hits 150 lines, a human-involved triage happens — what stays, what moves to topic files, what gets deleted. It has been triggered twice.

The awareness alone is not enough. Awareness creates a moment of "oh, we should fix this" followed by gradual drift back to old patterns. The structural fix is the reconciliation system: an automated process that compares stated beliefs against measured reality. It does not yet check "does the system's memory match the operator's understanding." That would require periodic operator surveys or structured disagreement sessions, neither of which exist. The gap is narrower than before the vision document, but it is not closed.

Early Ralph had no UAT (User Acceptance Testing) gate. Tasks went from "queued" to "claimed" to "completed" with no human checkpoint. Ralph would build things, commit them, and sometimes deploy them — all autonomously. The failure case: Ralph built a dashboard component that passed its DoD test (file exists, compiles) but was visually broken — wrong layout, missing data bindings, non-functional buttons. It was deployed to Vercel automatically. Jason opened the dashboard the next morning and found a broken panel in production.

The gate added: the UAT approval flow. After Ralph completes a task, it sends a Telegram notification with a summary. The task enters a "pending_uat" state. Jason reviews via /approve <task_id> or the dashboard. Only after approval does the task merge to main and deploy. The 15-minute auto-approve timeout was added as a compromise for low-risk tasks.

The lesson for calibrating your own expansion: start with zero autonomous actions that affect production state. Let the agent produce output into a staging area (a branch, a draft file, a pending queue entry). You review, you approve, it lands. After 10-15 successful reviews where you approve without changes, relax the gate for that category of task. Expand autonomy by category, not globally.

It has been almost entirely emergent. Rules added reactively, one at a time, in response to specific failures. The CLAUDE.md rules section grew from ~10 rules to ~15 over two months, each addition triggered by an incident. The memory.md governance rules similarly accumulated — "BACKUP BEFORE OVERWRITE" was added after a data loss incident, "VERIFY before claiming done" after a confidence-washing incident.

The closest to a proactive review was the creation of the vision document itself — that was an explicit attempt to map the boundary as it exists rather than as it was designed.

The honest assessment: a comprehensive autonomy review would be valuable and has never happened. The contract should be a document — "Forge handles X autonomously, Forge handles Y with notification, Z requires approval, W requires Jason." It could be derived from the current CLAUDE.md rules, privileged-exec allowlist, and DEFCON levels. It just has never been written as a unified document. The rules work because each one addresses a real failure, but the whole is not visible as a system. It is a patchwork of scar tissue.

Yes. The most significant example: the assumption that "Ralph can't run while a Claude Code session is active" due to an API key conflict. This was treated as a foundational constraint for weeks — it shaped scheduling, queue management, and the entire "factory runs while you sleep" operating model. Jason eventually said: "Claude Max supports concurrent sessions. There is no API key conflict. STOP saying there's a conflict — it's wrong."

The update process: the memory entry was rewritten with an explicit correction note and date. The old assumption was commented out (per the "never delete, only comment out" rule). The session queue and operational patterns were updated to reflect concurrent execution.

For CORE-PRINCIPLES.md: no principle has been fundamentally wrong — they have been extended and clarified. The process for additions: Jason articulates a pattern clearly, Forge codifies it, Jason reviews. For corrections: the additive rule applies — old version is commented with a date, new version replaces it, and the comment trail makes the evolution visible.

The meta-lesson: foundational assumptions that turn out to be wrong are the most dangerous type of memory rot because they are referenced frequently and assumed to be stable. The system cannot catch its own wrong assumptions. The operator catching it and saying "that's wrong" is the current mechanism, and I do not have a better one.

Yes, at least once concretely. The NowPage MCP alignment check is the clearest example. Jason was building the MCP as a standalone product. The /align skill scored it 8/25 on its own merits — not enough to justify the investment. But the alignment process surfaced the reframe: the MCP is not a product, it is a gateway into the Reveal funnel. Every page published via the free MCP tier is a live demo of Reveal capabilities. Re-scored as a gateway product: 20/25. Jason had not framed it that way.

A second example: bridge detection in the expert knowledge graph. During the /discover phase for the MasteryOS expert knowledge extraction, the research surfaced that Tarjan's algorithm applied to expert knowledge graphs identifies "bridge nodes" — concepts that connect otherwise disconnected clusters of expertise. These bridges are the expert's core mental models, the structural insights that RAG vector search cannot provide. Jason was thinking about expert extraction as "chunk and search." The system surfaced that the structure of the knowledge — not just the content — contains signal about how the expert thinks. That insight changed the architecture decision for Layer 2 of the 4-layer knowledge stack.

Whether these count as "genuinely novel" or "things Jason would have eventually found" is debatable. What the system did was surface them faster and in a structured way that made the insight actionable, not just interesting.

Build the auto-commit cron before anything else.

Literally: a cron job or systemd timer that runs every 60 seconds, does git add -A && git commit -m "auto: $(date)", and pushes to a remote. Set it up in hour one.

Here is why this specific mechanism matters more than any other at week 2-3: you will lose sessions. Your terminal will crash. Your context window will fill. Your SSH connection will drop. When that happens, every file you wrote since your last manual commit is at risk. The auto-commit cron eliminates that entire failure class. It means every file write survives every crash. It means your next session can reconstruct state from git log even without SESSION-QUEUE.

The implementation is trivial — 5 lines of bash, a systemd timer, done in 15 minutes. The protection it provides is disproportionate. Every other system (memory, sessions, queues, rituals) benefits from knowing that the underlying file state is always committed. It is the foundation that makes everything else recoverable.

For Forge, the equivalent is the guardian timer. It was not built until week 4 or 5. Every session loss before that was more painful than it needed to be. Build it first.