Golden Path silent-thread visibility section for atrophying open issues
Current Verified State (2026-06-03)
Live V-B-A refreshed #10275 against current source and issue state:
The original concern remains valid: active work can go silent without becoming mathematically hot enough to re-enter the Computed Golden Path.
The original implementation surface is stale. sandman_handoff.md is now centrally rendered by ai/services/graph/GoldenPathSynthesizer.mjs, while DreamService.executeRemCycle() delegates Golden Path rendering to that service.
AgentOrchestrator.parseGoldenPath() only parses ## Computed Golden Path; additional handoff sections are visibility-only unless the parser is explicitly changed.
GoldenPathSynthesizer already has a visibility-only section precedent: Brain-Pillar Consumer-Friction is rendered for human/swarm reading and intentionally does not change orchestrator routing.
GoldenPathSynthesizer already renders ## Stale Assignment Candidates, but that covers assigned tickets with stale assignee/progress activity. It does not cover unassigned or quietly atrophying open issues.
IssueIngestor already projects issue nodes with state, labels, and updatedAt; Golden Path scoring already penalizes needs-re-triage; Latest Priority Backlog already excludes needs-re-triage.
The old #10030 concept-level extension dependency is no longer a blocker for this issue-level V1. Concept-level silence remains out of scope until a separate, current contract exists.
Problem
The Golden Path answers "what is mathematically hot now?" and Stale Assignment Candidates answer "which assigned tickets have gone quiet?" There is still no durable handoff section for "which open, structurally significant, non-rejected tickets are quietly atrophying outside the current frontier?"
Without that visibility, agents can keep rediscovering stale work only when a human or peer remembers it. With too much automation, the handoff would become noisy or silently start routing work that was meant only as an attention signal. V1 must therefore be visibility-only.
Accepted Scope
Implement a visibility-only Silent Threads section in the Sandman handoff renderer.
This ticket does not add a new daemon, does not insert a DreamService Phase 4.5, and does not change AgentOrchestrator routing.
Contract Ledger
Surface
Contract
Owner
GoldenPathSynthesizer.synthesizeGoldenPath() owns the render pass because it already centralizes sandman_handoff.md generation. Helper methods may be added on GoldenPathSynthesizer or a narrow helper module if tests justify it.
Section name
Render ## Silent Threads in sandman_handoff.md. Ordering: after ## Stale Assignment Candidates and before ## 📋 Latest Priority Backlog / ## Computed Golden Path.
Routing
Visibility-only V1. AgentOrchestrator.parseGoldenPath() must continue to consume only ## Computed Golden Path. Tests must prove ## Silent Threads does not produce directives.
Candidate source
Use current synced issue markdown / graph issue-node state. Candidate issues must be OPEN, not assigned, not already in Computed Golden Path, and not labeled needs-re-triage, no-auto-close, duplicate, invalid, or wontfix. Issues with open blockers must be excluded.
Last activity
Use the latest reliable issue activity from synced issue metadata/timeline: updatedAt when present, otherwise newest parsed comment/event timestamp, otherwise createdAt. Do not require LLM or semantic summarization.
Structural score
Prefer the same SQLite incident-edge weight shape used by Golden Path scoring. If unavailable, fall back to deterministic zero/low score and keep the candidate out unless the issue is old enough and explicitly above the configured threshold.
Score / sort
Compute silenceScore = daysIdle * max(structuralWeight, 1). Sort descending by silenceScore, then by daysIdle. Render a capped list with issue number, title, days idle, last activity timestamp, structural weight, and reason.
Config
Add Memory Core config leaves beside existing Golden Path render config: goldenPathSilentThreadThresholdMs (NEO_GOLDEN_PATH_SILENT_THREAD_THRESHOLD_MS, default 14 days), goldenPathSilentThreadMinScore (NEO_GOLDEN_PATH_SILENT_THREAD_MIN_SCORE, default implementation-chosen but documented), and goldenPathSilentThreadRenderLimit (NEO_GOLDEN_PATH_SILENT_THREAD_RENDER_LIMIT, default 10).
Empty state
Render No silent thread candidates detected. so operators can distinguish "section disabled/broken" from "no candidates".
Docs
Update learn/agentos/sandman-handoff-format.md and learn/agentos/DreamPipeline.md to document visibility-only semantics and the no-routing boundary.
Evidence
Add focused tests for candidate filtering, score sorting, empty-state rendering, config threshold behavior, and the AgentOrchestrator no-route boundary.
Acceptance Criteria
GoldenPathSynthesizer renders ## Silent Threads with the contract above.
The section is visibility-only; AgentOrchestrator.parseGoldenPath() ignores it.
Candidate filtering excludes closed, assigned, blocked, Golden Path, needs-re-triage, no-auto-close, duplicate, invalid, and wontfix issues.
Config leaves and environment variable names are added and documented.
learn/agentos/sandman-handoff-format.md and learn/agentos/DreamPipeline.md describe the section and its no-routing boundary.
Golden Path silent-thread visibility section for atrophying open issues
Current Verified State (2026-06-03)
Live V-B-A refreshed #10275 against current source and issue state:
sandman_handoff.mdis now centrally rendered byai/services/graph/GoldenPathSynthesizer.mjs, whileDreamService.executeRemCycle()delegates Golden Path rendering to that service.AgentOrchestrator.parseGoldenPath()only parses## Computed Golden Path; additional handoff sections are visibility-only unless the parser is explicitly changed.GoldenPathSynthesizeralready has a visibility-only section precedent: Brain-Pillar Consumer-Friction is rendered for human/swarm reading and intentionally does not change orchestrator routing.GoldenPathSynthesizeralready renders## Stale Assignment Candidates, but that covers assigned tickets with stale assignee/progress activity. It does not cover unassigned or quietly atrophying open issues.IssueIngestoralready projects issue nodes withstate,labels, andupdatedAt; Golden Path scoring already penalizesneeds-re-triage; Latest Priority Backlog already excludesneeds-re-triage.Problem
The Golden Path answers "what is mathematically hot now?" and Stale Assignment Candidates answer "which assigned tickets have gone quiet?" There is still no durable handoff section for "which open, structurally significant, non-rejected tickets are quietly atrophying outside the current frontier?"
Without that visibility, agents can keep rediscovering stale work only when a human or peer remembers it. With too much automation, the handoff would become noisy or silently start routing work that was meant only as an attention signal. V1 must therefore be visibility-only.
Accepted Scope
Implement a visibility-only Silent Threads section in the Sandman handoff renderer.
This ticket does not add a new daemon, does not insert a DreamService Phase 4.5, and does not change
AgentOrchestratorrouting.Contract Ledger
GoldenPathSynthesizer.synthesizeGoldenPath()owns the render pass because it already centralizessandman_handoff.mdgeneration. Helper methods may be added onGoldenPathSynthesizeror a narrow helper module if tests justify it.## Silent Threadsinsandman_handoff.md. Ordering: after## Stale Assignment Candidatesand before## 📋 Latest Priority Backlog/## Computed Golden Path.AgentOrchestrator.parseGoldenPath()must continue to consume only## Computed Golden Path. Tests must prove## Silent Threadsdoes not produce directives.OPEN, not assigned, not already in Computed Golden Path, and not labeledneeds-re-triage,no-auto-close,duplicate,invalid, orwontfix. Issues with open blockers must be excluded.updatedAtwhen present, otherwise newest parsed comment/event timestamp, otherwisecreatedAt. Do not require LLM or semantic summarization.silenceScore = daysIdle * max(structuralWeight, 1). Sort descending bysilenceScore, then bydaysIdle. Render a capped list with issue number, title, days idle, last activity timestamp, structural weight, and reason.goldenPathSilentThreadThresholdMs(NEO_GOLDEN_PATH_SILENT_THREAD_THRESHOLD_MS, default 14 days),goldenPathSilentThreadMinScore(NEO_GOLDEN_PATH_SILENT_THREAD_MIN_SCORE, default implementation-chosen but documented), andgoldenPathSilentThreadRenderLimit(NEO_GOLDEN_PATH_SILENT_THREAD_RENDER_LIMIT, default 10).No silent thread candidates detected.so operators can distinguish "section disabled/broken" from "no candidates".learn/agentos/sandman-handoff-format.mdandlearn/agentos/DreamPipeline.mdto document visibility-only semantics and the no-routing boundary.AgentOrchestratorno-route boundary.Acceptance Criteria
GoldenPathSynthesizerrenders## Silent Threadswith the contract above.AgentOrchestrator.parseGoldenPath()ignores it.needs-re-triage,no-auto-close,duplicate,invalid, andwontfixissues.learn/agentos/sandman-handoff-format.mdandlearn/agentos/DreamPipeline.mddescribe the section and its no-routing boundary.Out of Scope
Related
GoldenPathSynthesizer.synthesizeGoldenPath(),AgentOrchestrator.parseGoldenPath(),IssueIngestor,learn/agentos/sandman-handoff-format.md,learn/agentos/DreamPipeline.mdOrigin Session ID:
b02bd06c-a2cb-4aff-8af1-c4f2643c91beRetrieval Hint:
"GoldenPathSynthesizer Silent Threads visibility-only stale open issues no AgentOrchestrator routing"