From b3ef048c28fdb71322e84932b4bd328acf2664d1 Mon Sep 17 00:00:00 2001 From: Steve Yegge Date: Sat, 20 Dec 2025 18:02:53 -0800 Subject: [PATCH] feat(mail): sort pinned messages first in inbox (gt-ngu1) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Add Pinned field to Message and BeadsMessage types, and implement sorting in listBeads() to show pinned messages first, then by priority, then by date. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 --- .beads/issues.jsonl | 4 ++++ internal/mail/mailbox.go | 32 ++++++++++++++++++++++++++++++++ internal/mail/types.go | 5 +++++ 3 files changed, 41 insertions(+) diff --git a/.beads/issues.jsonl b/.beads/issues.jsonl index ab0f6812..6496cbf9 100644 --- a/.beads/issues.jsonl +++ b/.beads/issues.jsonl @@ -117,6 +117,9 @@ {"id":"gt-92l","title":"Daemon: integration test with real lifecycle","description":"Need an end-to-end test that:\n1. Starts daemon\n2. Starts a test agent session\n3. Sends lifecycle request to daemon\n4. Verifies session was killed and restarted\n5. Cleans up\n\nCould use a mock 'agent' that's just a shell script.","status":"closed","priority":2,"issue_type":"task","created_at":"2025-12-18T13:38:17.261096-08:00","updated_at":"2025-12-19T17:22:52.555739-08:00","closed_at":"2025-12-19T16:31:23.543204-08:00","dependencies":[{"issue_id":"gt-92l","depends_on_id":"gt-99m","type":"blocks","created_at":"2025-12-18T13:38:26.962642-08:00","created_by":"daemon"}]} {"id":"gt-95x","title":"Remove stale migration docs from gastown-py","description":"The gastown-py repo has migration-related documentation that is now misinformation since we have made design decisions. Remove or clearly mark as obsolete: any docs about migration paths, old architecture assumptions, or superseded designs.","status":"closed","priority":1,"issue_type":"task","created_at":"2025-12-15T20:24:08.642373-08:00","updated_at":"2025-12-15T21:04:39.516436-08:00","closed_at":"2025-12-15T21:04:39.516436-08:00"} {"id":"gt-974","title":"Refinery background daemon mode","description":"The refinery 'gt refinery start' command only works in foreground mode (--foreground). Need to implement background daemon mode for production use.\n\nOptions:\n1. Use a separate tmux session for the refinery\n2. Implement proper daemonization\n3. Use Claude Code session for the refinery agent\n\nFor MVP, option 1 (tmux session) is probably simplest.","status":"closed","priority":1,"issue_type":"task","created_at":"2025-12-16T22:08:04.799753-08:00","updated_at":"2025-12-19T14:27:33.858745-08:00","closed_at":"2025-12-19T14:27:33.858745-08:00"} +{"id":"gt-975","title":"Molecule execution support for polecats and crew","description":"Enable agents to run bonded molecules through the full lifecycle.\n\n## The Model\n1. BOND - bd mol bond \u003ctemplate\u003e --assignee \u003cidentity\u003e\n Creates concrete issues, assigns root to agent\n\n2. DISCOVER - Agent finds assigned molecules via bd ready\n DAG structure shows unblocked steps\n\n3. WORK - Agent works through DAG, closing steps as done\n Can delegate children to lower-tier agents (haiku)\n\n4. SURVIVE - Agent dies → beads persist\n Any agent resumes from DAG state\n\n5. SUPERVISE - Witness monitors for stalled molecules\n Nudges owner or reassigns if dead\n\n## Questions to Resolve\n- Seed node terminology: seed vs root vs pole vs nucleus\n- Assignee inheritance: single owner vs delegation model\n- Stall detection: heartbeat vs activity timeout vs session monitoring\n\n## Implementation\n- Polecat startup: check for assigned molecules\n- Polecat work loop: follow molecule DAG\n- Witness: monitor molecule progress, detect stalls\n- Mayor: can assign molecules, handle escalations\n\n## Depends On\n- beads: bd mol bond command (bd-usro in beads repo)","status":"open","priority":1,"issue_type":"feature","created_at":"2025-12-20T16:57:01.09104-08:00","updated_at":"2025-12-20T16:57:01.09104-08:00"} +{"id":"gt-976","title":"Add crew lifecycle support to Deacon","description":"Currently crew sessions (like gastown/crew/max, beads/crew/dave) are marked as 'human-managed' and excluded from automated lifecycle.\n\n## Current State\n- `getManager(RoleCrew)` returns `\"human\"` (handoff.go:273)\n- `gt handoff` for crew just prints a message, no lifecycle request sent\n- Crew cannot request automated refresh from Deacon\n\n## Desired State\nCrew members should be able to request lifecycle actions from Deacon:\n- `gt handoff --cycle` sends request to Deacon, which kills/restarts the crew session\n- Useful when: context full, running molecules that need fresh session, automation\n\n## Implementation\n1. Change `getManager(RoleCrew)` to return `\"deacon/\"` (or new crew manager)\n2. Teach Deacon to recognize crew session naming pattern\n3. Add crew to Deacon's respawn loop handling\n4. Test with `gt nudge` for reliable message delivery\n\n## Use Case\nRunning a molecule (e.g., version-bump) and discovering mid-workflow that a fresh session is needed. Agent should be able to request refresh automatically rather than requiring human intervention.\n\n## Related\n- gt nudge: reliable message delivery to Claude sessions\n- bd mol bond: molecule instantiation (coming in beads)","status":"open","priority":2,"issue_type":"feature","created_at":"2025-12-20T17:19:46.854829-08:00","updated_at":"2025-12-20T17:19:46.854829-08:00"} +{"id":"gt-977","title":"Work request: gt-976 crew lifecycle support","description":"Hey Max, filed gt-976 for you - adding crew lifecycle support to Deacon.\n\nCurrently crew is 'human-managed' and can't request automated refresh. Would be useful for molecules that need fresh sessions mid-workflow.\n\nKey changes:\n- getManager(RoleCrew) → return deacon/ instead of human\n- Teach Deacon crew session patterns\n- Test with gt nudge\n\nPriority 2, no rush but would unblock molecule automation for crew.\n\n- Dave (beads/crew/dave)","status":"open","priority":2,"issue_type":"message","assignee":"gastown/crew/max","created_at":"2025-12-20T17:19:55.964718-08:00","updated_at":"2025-12-20T17:19:55.964718-08:00","sender":"Steve Yegge","ephemeral":true} {"id":"gt-98oo","title":"Merge: gt-y5o","description":"branch: polecat/Doof\ntarget: main\nsource_issue: gt-y5o\nrig: gastown","status":"closed","priority":2,"issue_type":"merge-request","created_at":"2025-12-19T16:29:03.837448-08:00","updated_at":"2025-12-19T18:26:14.102603-08:00","closed_at":"2025-12-19T17:47:03.619784-08:00"} {"id":"gt-99a","title":"Add unit tests for daemon package","description":"The daemon package has no unit tests. Need tests for:\n- Config and state serialization\n- Session name pattern matching (isWitnessSession)\n- Lifecycle request parsing\n- Identity to session mapping","status":"closed","priority":2,"issue_type":"task","created_at":"2025-12-18T13:38:10.458609-08:00","updated_at":"2025-12-19T17:22:52.552189-08:00","closed_at":"2025-12-19T16:17:43.92102-08:00","dependencies":[{"issue_id":"gt-99a","depends_on_id":"gt-99m","type":"blocks","created_at":"2025-12-18T13:38:26.466501-08:00","created_by":"daemon"}]} {"id":"gt-99m","title":"gt daemon: Background service management","description":"## Summary\n\nONE daemon for all Gas Town - a simple Go process (not a Claude agent) that:\n1. Pokes agents periodically (heartbeat)\n2. Processes lifecycle requests\n3. Restarts sessions when agents request cycling\n\n## Architecture\n\nDaemon (gt daemon)\n- Pokes Mayor: \"HEARTBEAT: check your rigs\"\n- Pokes each Witness: \"HEARTBEAT: check your workers\"\n- Has inbox at daemon/ for lifecycle requests\n- Restarts sessions on cycle requests\n\n## NOT the daemon's job:\n- Making decisions (Witnesses do that)\n- Running Claude (it's a Go process)\n- Processing work (polecats do that)\n- Direct polecat management (Witnesses do that)\n\nThe daemon is a **dumb scheduler** - poke things, execute lifecycle requests. All intelligence is in agents.\n\n## Commands\n\n- gt daemon start: Start daemon (background)\n- gt daemon stop: Stop daemon\n- gt daemon status: Show daemon status\n- gt daemon logs: View daemon logs\n\n## Daemon Loop\n\nEvery heartbeat interval:\n1. Poke Mayor\n2. For each rig: Poke Witness\n3. Process lifecycle requests from daemon/ inbox\n4. Check for dead sessions, restart if cycle requested\n\n## Lifecycle Request Handling\n\nDaemon checks its inbox (daemon/) for lifecycle requests:\n- From Mayor: cycle/restart Mayor session\n- From Witnesses: cycle/restart Witness session\n\nOn request:\n1. Verify agent state shows requesting_cycle\n2. Kill session\n3. Start new session\n4. Clear requesting_cycle flag\n\n## Poke Protocol\n\nPoke = tmux inject \"HEARTBEAT: do your job\"\n- Agent ignores if already working\n- Agent wakes up if idle\n- Idempotent - multiple pokes are fine\n\n## Lifecycle Hierarchy\n\n- Daemon manages: Mayor, all Witnesses\n- Witness manages: Polecats, Refinery (per rig)\n- Crew: self-managed (human workspace)\n\n## Related Issues\n\n- gt-kmn.11: Daemon heartbeat details\n- gt-gby: gt handoff command (unified lifecycle)\n- gt-u1j.9: Fold witness daemon into this","status":"closed","priority":1,"issue_type":"task","created_at":"2025-12-17T21:50:09.763719-08:00","updated_at":"2025-12-19T12:05:27.33958-08:00","closed_at":"2025-12-19T12:05:27.33958-08:00","dependencies":[{"issue_id":"gt-99m","depends_on_id":"gt-hw6","type":"blocks","created_at":"2025-12-17T22:23:43.253877-08:00","created_by":"daemon"}]} @@ -294,6 +297,7 @@ {"id":"gt-n7z7","title":"Bug: refinery --foreground detects parent session as already running","description":"When gt refinery start gastown runs:\n1. Creates tmux session gt-gastown-refinery\n2. Sends 'gt refinery start gastown --foreground' into the session\n3. The foreground command checks HasSession() - finds the session it's inside\n4. Returns 'already running' error\n\nThe foreground mode check should either:\n- Skip the tmux session check (only check PID)\n- Use a different indicator that the daemon loop is running\n- Pass a flag to indicate we're being called from the background starter\n\nWorkaround: Manually run 'gt refinery start gastown --foreground' from a fresh session.","status":"closed","priority":1,"issue_type":"bug","created_at":"2025-12-20T00:56:20.326369-08:00","updated_at":"2025-12-20T03:52:11.20518-08:00","closed_at":"2025-12-20T03:52:11.20518-08:00","close_reason":"Fixed: Added timeout warnings to handoff wait, fixed refinery foreground race condition"} {"id":"gt-nam3","title":"Update docs to reflect molecule-first paradigm","description":"Gas Town is fundamentally a molecule execution engine. Documentation should reflect this more clearly.\n\n## Issues Found\n\n### 1. gt spawn examples show molecule as optional\nREADME.md line 116: `gt spawn --issue \u003cid\u003e # Start polecat on issue`\nShould emphasize: polecats execute molecules, not just issues.\n\n### 2. Architecture.md spawn examples inconsistent\nLine 344 shows molecule: `gt spawn --issue gt-xyz --molecule mol-engineer-in-box`\nLine 1434 shows without: `gt spawn --issue \u003cid\u003e`\n\n### 3. Config vs molecule distinction not clear\noutposts.yaml shows static policy - should note when molecules apply.\n\n### 4. Operational molecules section is good but buried\nLines 430-566 cover operational molecules well. Should be more prominent.\n\n## Updates Needed\n- [ ] README: Update spawn examples to show molecule usage\n- [ ] architecture.md: Ensure all spawn examples include molecules\n- [ ] architecture.md: Add section on \"when config vs molecule\"\n- [ ] architecture.md: Move operational molecules higher in document\n- [ ] Add principle: \"If it requires cognition, it's a molecule\"\n- [ ] federation-design.md: Note that policy can escalate to mol-outpost-assign\n\n## Key Message\nGas Town doesn't spawn workers on issues. It spawns workers on molecules.\nThe issue is just the seed data for the molecule execution.","status":"closed","priority":1,"issue_type":"task","created_at":"2025-12-20T03:26:31.842406-08:00","updated_at":"2025-12-20T09:26:21.813833-08:00","closed_at":"2025-12-20T09:26:21.813833-08:00","close_reason":"Updated docs with molecule-first paradigm - all spawn examples include molecules, added Config vs Molecule section with cognition principle, updated federation-design.md with policy escalation note"} {"id":"gt-ngkd","title":"Work on gt-ogr: Fix rig count in tmux status bar. The cou...","description":"Work on gt-ogr: Fix rig count in tmux status bar. The count is showing wrong. Run 'bd show gt-ogr' for details.","status":"closed","priority":2,"issue_type":"task","assignee":"gastown/slit","created_at":"2025-12-20T07:53:01.093695-08:00","updated_at":"2025-12-20T07:59:51.445668-08:00","closed_at":"2025-12-20T07:59:51.445668-08:00","close_reason":"Fixed rig count logic by adding extractRigFromSession() to handle both witness naming patterns (gt-\u003crig\u003e-witness and gt-witness-\u003crig\u003e), and isPolecatSession() to exclude witness/refinery/crew from polecat count"} +{"id":"gt-ngu1","title":"Pinned beads should appear first in mail inbox","description":"Currently bd mail inbox sorts by priority then date, but pinned beads (handoff context) should always appear at the top.\n\n**Current behavior:**\n- Pinned beads mixed in with regular mail based on priority/date\n\n**Expected behavior:**\n- Pinned beads always first in inbox (before priority sorting)\n- This enables handoff beads to be the default first item an agent sees\n\n**Implementation:**\n1. In mail.go runMailInbox(), after filtering, sort pinned beads to top\n2. Within pinned and non-pinned groups, maintain priority/date sort\n\n**Related:**\n- gt-r8ej: Implement pinned beads for handoff state\n- gt-8h4: Pinned Beads epic\n\n**Acceptance criteria:**\n- bd mail inbox shows pinned beads first\n- Pinned beads still sorted by priority/date among themselves\n- Non-pinned mail sorted normally after pinned section","status":"open","priority":1,"issue_type":"task","created_at":"2025-12-20T17:45:24.133521-08:00","updated_at":"2025-12-20T17:45:24.133521-08:00","dependencies":[{"issue_id":"gt-ngu1","depends_on_id":"gt-8h4","type":"parent-child","created_at":"2025-12-20T17:45:31.978176-08:00","created_by":"daemon"}]} {"id":"gt-ni6a","title":"Witness role template + CLAUDE.md","description":"Create the Witness agent's role context:\n\n1. internal/templates/roles/witness.md.tmpl\n - Witness responsibilities (polecat lifecycle)\n - Core loop description\n - Commands available (gt polecats, bd ready, etc)\n - Escalation protocol\n\n2. Generate CLAUDE.md for witness/ directories\n - Context about the rig\n - Mail address: \u003crig\u003e/witness\n - Startup protocol (gt prime, check inbox)\n\nThe Witness is the per-rig 'pit boss' - NOT a global coordinator. It manages polecats for ONE rig only.","status":"closed","priority":1,"issue_type":"task","created_at":"2025-12-20T03:14:18.617496-08:00","updated_at":"2025-12-20T03:54:13.697998-08:00","closed_at":"2025-12-20T03:54:13.697998-08:00","close_reason":"Fixed gt mail ack → gt mail delete in witness template; template renders correctly","dependencies":[{"issue_id":"gt-ni6a","depends_on_id":"gt-53w6","type":"parent-child","created_at":"2025-12-20T03:14:37.105264-08:00","created_by":"daemon"}]} {"id":"gt-njr","title":"Engineer session restart protocol","description":"Implement session restart flow for when the Engineer needs to split work:\n\n1. Engineer creates subtask(s) in Beads assigned to self\n2. Engineer sends handoff mail to self (🤝 HANDOFF)\n3. Engineer sends restart request to Witness\n4. Witness verifies:\n - Handoff mail exists in Engineer outbox/sent\n - Subtasks filed in Beads\n5. Witness restarts the Refinery session (new Engineer context)\n\nThis enables \"occasionally consistent, eventually convergent\" work patterns.\nThe Refinery continues; the Engineer gets fresh context.","status":"open","priority":1,"issue_type":"task","created_at":"2025-12-16T23:02:48.22994-08:00","updated_at":"2025-12-16T23:07:42.05363-08:00","dependencies":[{"issue_id":"gt-njr","depends_on_id":"gt-h5n","type":"blocks","created_at":"2025-12-16T23:02:56.148564-08:00","created_by":"daemon"}]} {"id":"gt-oc2","title":"Daemon: proper rig discovery","description":"Currently discovers rigs by scanning tmux session names for gt-*-witness pattern. Should instead:\n- Read rigs from mayor/rigs.json\n- Or scan town directory for .gastown subdirs\n- Handle rigs that exist but don't have running witnesses","status":"closed","priority":2,"issue_type":"task","created_at":"2025-12-18T13:38:15.825299-08:00","updated_at":"2025-12-19T17:22:52.554474-08:00","closed_at":"2025-12-19T16:28:39.497935-08:00","dependencies":[{"issue_id":"gt-oc2","depends_on_id":"gt-99m","type":"blocks","created_at":"2025-12-18T13:38:26.826697-08:00","created_by":"daemon"}]} diff --git a/internal/mail/mailbox.go b/internal/mail/mailbox.go index ad6b8c06..f11af90e 100644 --- a/internal/mail/mailbox.go +++ b/internal/mail/mailbox.go @@ -105,9 +105,41 @@ func (m *Mailbox) listBeads() ([]*Message, error) { messages = append(messages, bm.ToMessage()) } + // Sort: pinned first, then by priority (urgent first), then by date (newest first) + sort.Slice(messages, func(i, j int) bool { + // Pinned messages always come first + if messages[i].Pinned != messages[j].Pinned { + return messages[i].Pinned + } + // Within same pinned status, sort by priority (urgent > high > normal > low) + pi := priorityOrder(messages[i].Priority) + pj := priorityOrder(messages[j].Priority) + if pi != pj { + return pi < pj + } + // Within same priority, sort by date (newest first) + return messages[i].Timestamp.After(messages[j].Timestamp) + }) + return messages, nil } +// priorityOrder returns sort order for priority (lower = more urgent). +func priorityOrder(p Priority) int { + switch p { + case PriorityUrgent: + return 0 + case PriorityHigh: + return 1 + case PriorityNormal: + return 2 + case PriorityLow: + return 3 + default: + return 2 + } +} + func (m *Mailbox) listLegacy() ([]*Message, error) { file, err := os.Open(m.path) if err != nil { diff --git a/internal/mail/types.go b/internal/mail/types.go index a4cb5cf8..4c791c53 100644 --- a/internal/mail/types.go +++ b/internal/mail/types.go @@ -78,6 +78,9 @@ type Message struct { // Read indicates if the message has been read (closed in beads). Read bool `json:"read"` + // Pinned indicates if the message is pinned (persistent context marker). + Pinned bool `json:"pinned,omitempty"` + // Priority is the message priority. Priority Priority `json:"priority"` @@ -151,6 +154,7 @@ type BeadsMessage struct { Assignee string `json:"assignee"` // To identity Priority int `json:"priority"` // 0=urgent, 1=high, 2=normal, 3=low Status string `json:"status"` // open=unread, closed=read + Pinned bool `json:"pinned"` // Persistent context marker CreatedAt time.Time `json:"created_at"` Type string `json:"type,omitempty"` // Message type ThreadID string `json:"thread_id,omitempty"` // Thread identifier @@ -187,6 +191,7 @@ func (bm *BeadsMessage) ToMessage() *Message { Body: bm.Description, Timestamp: bm.CreatedAt, Read: bm.Status == "closed", + Pinned: bm.Pinned, Priority: priority, Type: msgType, ThreadID: bm.ThreadID,