feat: infrastructure-level work tracking (project management, not agent monitoring)

[raykao]

Problem

Agents are unreliable at maintaining project-level work state through behavioral conventions. In practice, instructing agents to "update the dashboard after every task" via AGENTS.md fails because:

1. Agents forget - behavioral checklist items compete with the primary task for attention and get dropped
2. Agents corrupt state - overwriting a GitHub Issue body with stale data, truncating rows, losing information that was added by a previous session
3. No recovery - GitHub Issue bodies have no revision history; once overwritten, previous state is gone

We've experienced all three failure modes running a manually maintained dashboard issue that tracks active work streams, research branches, and completed milestones across repos. We've also seen Beads (bd) task tracking commands get skipped unless explicitly prompted.

The core insight: agent behavioral conventions are not reliable enough for state management. The solution needs to be infrastructure-level - something the bridge handles automatically, not something agents are told to do.

What we actually need

Portfolio-level work tracking across repos and agents. Not "which agents are online" (the dashboard covers that), but:

• What projects/tasks exist across repos
• What's active, paused, blocked, done
• What research is in progress (branches, docs)
• What PRs and epics are open, where
• Historical record of completed work

This is the "what are we working on" view, not the "are agents healthy" view.

Design constraints learned from failure

1. Source of truth must be git-versioned - a markdown file in the workspace, not a GitHub Issue body. Git history provides recovery from accidental overwrites. The issue can be a regenerable mirror.
2. Updates should not depend on agent memory - the bridge or session hooks should capture work state automatically from observable signals (git activity, GitHub API events, session state changes) rather than relying on agents to self-report.
3. Append-friendly, not overwrite-friendly - the storage format should make it hard to accidentally lose prior entries. Appending a new row is safer than rewriting the entire document.
4. Cross-session durable - must survive bridge restarts, session resets, and agent context window limits.

Possible approaches

A: Bridge-native work journal (automatic)

The bridge automatically logs significant events to a per-workspace work journal:

• Session created/destroyed (with workspace, agent, channel)
• Git commits pushed (detected via hooks or post-session)
• PRs opened/merged (detected via gh activity)
• Beads tasks created/closed

This requires no agent cooperation. The journal is append-only and git-versioned.

B: Session hooks with structured output (semi-automatic)

sessionEnd hooks already fire when a session closes. A hook could:

• Capture a structured summary of what changed (files modified, commits made, tools called)
• Append to a work log file
• Optionally sync to a GitHub Issue

This is partially automatic (the hook fires reliably) but depends on the hook implementation being robust.

C: Periodic bridge-level aggregation (automatic)

A scheduled bridge task that periodically:

• Scans configured workspaces for recent git activity (git log --since)
• Queries GitHub for open PRs and issues across configured repos
• Queries Beads for open tasks
• Renders a work board from aggregated data
• Writes to a file and optionally mirrors to a GitHub Issue

No agent involvement at all. Pure infrastructure.

Relation to prior work

• Supersedes #165 (Work Board epic, closed as overscoped and drifted from intent)
• Complements copilot-bridge-dashboard (runtime monitoring, not project management)
• Related research: research/work-board.md and research/cross-channel-visibility.md in raykao/dark-factory

Open questions

1. Should this live in the bridge core, or as an extension/plugin (like the dashboard)?
2. What's the right granularity - per-workspace journals, or a single aggregated board?
3. Is sessionEnd hook reliable enough to be the primary capture point, or does it need a bridge-level fallback?
4. How does this interact with the dashboard - should the dashboard consume the work journal as a data source?