karashiiro.moe / 9plan

Fork 0

🐱 Medium-horizon agent planning MCP server

Fork 0

9plan docs future-work.md

10 kB

Markdown

at main

karashiiro · Commit design docs · 8mo ago

fb290d1f

9plan Future Work and Non-Goals #

This document captures ideas that were explicitly considered and deferred, features that don't fit the current design, and potential enhancements for later versions.

Explicit Non-Goals #

These are things 9plan intentionally does NOT do. They were considered and rejected, not overlooked.

Multi-Agent Concurrency #

What it would be: Multiple agents working on the same session simultaneously.

Why not:

The "one active plan" model assumes single execution
Queue ordering becomes complex with concurrent pulls
Locking and conflict resolution add significant complexity
Target use case is single-agent, long-horizon tasks

Workaround: Create separate sessions for parallel workstreams; coordinate manually.

Priority-Based Ordering #

What it would be: Numeric priorities (1-10) or priority tiers (high/medium/low).

Why not:

Creates failure mode where low-priority work is abandoned
Requires agents to calibrate priorities against existing items
Front/back positioning is simpler and matches how work is discovered

Workaround: Use front position for urgent work; reorder via defer if needed.

Cross-Session Dependencies #

What it would be: Plans in one session depending on outputs from another session.

Why not:

Breaks session isolation and "must empty" semantics
Session scoping keeps search results predictable
Different sessions may use same terms for different things

Workaround: Complete dependent session first; manually reference its outputs.

Plan Versioning / Rollback #

What it would be: Full history of plan changes with ability to revert.

Why not:

Notes section provides partial history (deferral reasons, checkpoints)
Full versioning adds significant storage and complexity
Plans are disposable—re-plan rather than rollback

Workaround: Copy important plan state to Notes before major changes.

Automatic Dependency Enforcement #

What it would be: System blocks plan execution until declared dependencies complete.

Why not:

Dependencies are semantic, not ID-based; hard to verify automatically
Decomposition means children produce outputs, not parents
Would require dependency graph management

Workaround: Defer plans that can't proceed; semantic search finds outputs.

Project-Level Organization #

What it would be: Sessions grouped into projects with shared history.

Why not:

Adds organizational layer that complicates core model
Session isolation is valuable for predictability
"Project" boundaries are often unclear

Workaround: Use naming conventions (e.g., myapp-auth, myapp-frontend).

Real-Time Collaboration #

What it would be: Multiple users viewing/editing session state simultaneously.

Why not:

Single-agent execution model
Would require sync protocol, conflict resolution
Not the target use case

Workaround: One user at a time; use session resume to hand off.

Plan Templates #

What it would be: Pre-defined plan structures for common patterns (research, implementation, testing).

Why not (for now):

Current plan format is simple enough to create ad-hoc
Templates might constrain creative decomposition
Can be added later without breaking changes

Workaround: Copy-paste from previous plans; agents can develop their own patterns.

Potential Future Enhancements #

These are features that COULD be valuable but aren't prioritized for v1.

Batch Add Operation #

Problem: Front-insertion reversal requires adding plans in reverse order.

Enhancement: 9plan_queue_add_batch accepting ordered list of plans, inserting in specified order.

Example:

{
  "tool": "9plan_queue_add_batch",
  "arguments": {
    "plans": [
      { "goal": "Plan A", ... },
      { "goal": "Plan B", ... },
      { "goal": "Plan C", ... }
    ],
    "position": "front"
  }
}

Result: [A, B, C, ...rest] (correct order)

Complexity: Low—queue manipulation is straightforward.

Priority: Medium—solves real usability issue.

HTTP Transport #

Problem: stdio transport requires server to be spawned by client.

Enhancement: HTTP/SSE transport for remote access, web clients.

Benefits:

Web-based interfaces could connect
Multiple clients could connect (though still single-agent)
Easier debugging/inspection

Complexity: Medium—transport layer exists, need HTTP endpoints.

Priority: Low—stdio works for current use cases.

Session Export/Import #

Problem: Sessions are tied to local filesystem; can't share or move.

Enhancement: Export session to portable format; import elsewhere.

Example:

9plan export amber-quiet-river > session.json
9plan import session.json  # creates new session

Benefits:

Share sessions between machines
Backup/restore beyond filesystem copy
Hand off sessions to other users

Complexity: Medium—need serialization format, ID remapping.

Priority: Low—filesystem copy works for most cases.

Enhanced Search Operators #

Problem: FTS5 search is keyword-based; can't express complex queries.

Enhancement: Support field-specific search, date ranges, status filters.

Example:

{
  "tool": "9plan_history_search",
  "arguments": {
    "query": "goal:authentication outputs:client",
    "completed_after": "2024-01-01"
  }
}

Complexity: Medium—need query parser, extended FTS5 usage.

Priority: Low—current search works for dependency resolution.

Progress Indicators #

Problem: No visibility into session progress without resuming.

Enhancement: 9plan_session_status providing quick overview without full resume.

Example response:

Session: amber-quiet-river
Status: In progress
Progress: 4/7 plans complete (57%)
Active: k7f3m (since 2 hours ago)

Complexity: Low—data already available.

Priority: Low—resume provides this information.

Plan Estimation #

Problem: No way to estimate remaining work or session duration.

Enhancement: Optional time/effort estimates on plans; rollup to session level.

Example:

{
  "tool": "9plan_queue_add",
  "arguments": {
    "goal": "Implement caching",
    "estimate": "2 hours",
    ...
  }
}

Complexity: Medium—need estimation tracking, rollup logic.

Priority: Low—estimation is notoriously unreliable for development tasks.

Webhook Notifications #

Problem: No way to notify external systems of plan completions.

Enhancement: Configure webhooks for session events.

Use cases:

Slack notification when session completes
Trigger CI/CD on certain plan completions
Audit logging to external system

Complexity: High—need configuration, retry logic, security.

Priority: Low—manual notification works for current use cases.

LLM-Assisted History Search #

Problem: Semantic search depends on exact keyword matches.

Enhancement: Use embeddings or LLM reranking for better search relevance.

Benefits:

Find outputs even with terminology mismatch
"Smart" understanding of what agent is looking for

Complexity: High—need embedding infrastructure or LLM integration.

Priority: Low—explicit output descriptions work well enough.

Ideas Explicitly Rejected #

These were considered more deeply and rejected for specific reasons.

Hierarchical Queue (Parent-Child Tracking) #

Idea: Maintain explicit parent-child relationships in queue structure.

Rejected because:

Adds complexity to queue management
Semantic dependency resolution handles relationships
Notes capture decomposition for aggregation
Would complicate front/back positioning semantics

Automatic Plan Splitting #

Idea: System detects large plans and suggests/performs decomposition.

Rejected because:

"Large" is subjective and context-dependent
Agent is better positioned to know when decomposition helps
Would require understanding plan content semantically

Undo/Redo Operations #

Idea: Undo last operation (plan add, complete, defer, discard).

Rejected because:

Many operations have side effects (file deletion, DB changes)
Would require transaction log, complex state management
Defer provides "soft undo" for plan lifecycle
Re-planning is idiomatic for mistakes

Session Archiving #

Idea: Completed sessions move to archive, freeing active space.

Rejected because:

Filesystem storage is cheap
Archiving adds state (is it archived or deleted?)
Manual cleanup is simple and controllable

Plan Dependencies via DAG #

Idea: Express dependencies as directed acyclic graph, with topological ordering.

Rejected because:

Requires knowing all dependencies upfront
Doesn't handle dynamically discovered work
Cross-branch dependencies only visible at decomposition time
Semantic resolution is more flexible

When to Reconsider #

These non-goals or deferrals should be reconsidered if:

Feature	Reconsider If...
Multi-agent concurrency	Use cases emerge requiring parallel execution
Priority ordering	Users consistently struggle with front/back
Cross-session deps	Common pattern of related sessions emerges
HTTP transport	Web-based interfaces become priority
Batch add	Decomposition usability complaints increase
Plan templates	Common patterns stabilize across users

Contributing Ideas #

If you have ideas for 9plan:

Check this document first—it may already be addressed
Consider the design principles—does it fit?
- Self-contained plans
- Semantic dependencies
- Single queue discipline
- Session isolation
Describe the use case—what problem does it solve?
Suggest an approach—how would it work?

Ideas that conflict with core principles need strong justification. Ideas that extend capabilities without breaking principles are more likely to be adopted.