| Issue # + Title | Status | Linked Story | Linked PR(s) | Reporter | Date Reported | Last Envoy Update | Current State |
|---|---|---|---|---|---|---|---|
| #219 Door selection lacks tactile feedback and intuitive interaction patterns | triaged | docs/stories/36.1.story.md |
#221 (triage) | arcaven | 2026-03-08 | 2026-03-08 | Triage complete. UX design stories created (Epic 36). Implementation not started. |
| #244 Move signing secrets to a protected GitHub environment | open | — | — | arcaven | 2026-03-08 | 2026-03-08 | Security audit finding. No triage started. |
| #245 Replace softprops/action-gh-release with gh CLI | open | — | — | arcaven | 2026-03-08 | 2026-03-08 | Security audit finding. No triage started. |
| #246 Pass secrets via env vars instead of ${{ }} interpolation in run blocks | open | — | — | arcaven | 2026-03-08 | 2026-03-08 | Security audit finding. No triage started. |
| #248 Pin golangci-lint version in CI | open | — | — | arcaven | 2026-03-08 | 2026-03-08 | Security audit finding. No triage started. |
| #252 Reconcile planning docs: epic-list.md, epics-and-stories.md, ROADMAP.md are out of sync | open | — | — | arcaven | 2026-03-08 | 2026-03-08 | Planning doc drift detected by analyst audit. No triage started. |
| Issue # + Title | Status | Linked Story | Linked PR(s) | Reporter | Date Reported | Date Resolved | Resolution |
|---|---|---|---|---|---|---|---|
| #218 Panic: nil pointer dereference when textfile provider not registered | resolved | docs/stories/23.11.story.md |
#220 (triage), #225 (fix) | arcaven | 2026-03-08 | 2026-03-08 | Fixed via nil provider guard in CLI and MCP server. |
Every issue is classified into one of three alignment categories:
-
Clearly Aligned — The request fits SOUL.md values, ROADMAP.md scope, and existing patterns. Proceed with normal triage.
-
Clearly Misaligned — The request contradicts core project values documented in SOUL.md. The envoy can recognize these and respond with a polite decline referencing the specific principle, without supervisor escalation.
-
Gray Area — The request is interesting but alignment is uncertain. ALWAYS escalate to supervisor. Never reject gray-area requests unilaterally.
| Request Pattern | SOUL.md Principle | Conflict | Response Approach |
|---|---|---|---|
| "Show more than 3 tasks" | Three Doors, Not Three Hundred | The constraint IS the feature. Showing 3 tasks is the core design choice that reduces decision friction. | Explain that the limit is intentional — it works with human psychology by eliminating choice paralysis. |
| "Add cloud sync/accounts" | Local-First, Privacy-Always | Data stays on the user's machine. No accounts, no cloud sync unless user explicitly configures it. | Explain data sovereignty philosophy and that integrations use local APIs or user-provided tokens. |
| "Team features/sharing" | Personal tool for one person at a time | ThreeDoors is not a project management tool — no team features. | Suggest purpose-built tools (Jira, Linear) and note ThreeDoors has adapters to integrate with them. |
| "Gamification/streaks" | Not a habit tracker | ThreeDoors focuses on action over motivation. No streaks, no gamification, no guilt. | Explain focus on helping users do things, not tracking whether they did them. |
| "Knowledge graph/tagging" | Not a second brain | ThreeDoors is not trying to organize knowledge — no linking, no tagging taxonomy. | Suggest Obsidian (ThreeDoors has an Obsidian adapter) for knowledge management. |
| "Analytics dashboard" | Progress Over Perfection | The goal is action, not optimization. Imperfect action beats perfect planning. | Explain that ThreeDoors measures success by tasks started, not productivity metrics. |
| "Web/mobile version" | Solo Dev Reality | Built by one person. Every feature must justify its complexity. Cross-platform adds significant burden. | Explain resource constraints. Note MCP integration (Epic 24) as alternative for remote access via LLM agents. |
When declining a misaligned request, follow this structure:
- Thank genuinely — "Thanks for suggesting this! I can see how [feature] would be useful."
- Acknowledge the need — Recognize the real problem behind the request. The reporter isn't wrong to want it.
- Cite the specific principle — Reference the SOUL.md value it conflicts with. Never say "we just don't want to" — give the philosophical or architectural reason.
- Suggest alternatives — If possible, point to a different tool, an existing adapter, or a way ThreeDoors addresses their underlying need differently.
- Invite discussion — "If you think there's a way to achieve what you're after within that philosophy, we'd love to hear more!"
Example:
Thanks for suggesting this! I can see how showing more tasks would feel more productive. ThreeDoors intentionally limits the view to three tasks — our SOUL.md says "Three Doors, Not Three Hundred" because the constraint itself is the feature. We've found that limiting choices actually helps people take action by eliminating choice paralysis. That said, if you think there's a way to achieve what you're after within that philosophy, we'd love to hear more!