# 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**:
```json
{
  "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**:
```bash
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**:
```json
{
  "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**:
```json
{
  "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:

1. **Check this document first**—it may already be addressed
2. **Consider the design principles**—does it fit?
   - Self-contained plans
   - Semantic dependencies
   - Single queue discipline
   - Session isolation
3. **Describe the use case**—what problem does it solve?
4. **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.