Add sprint 26-33 roadmap plans and progress update

This commit is contained in:
Bill
2026-02-16 23:30:36 -07:00
parent ff7be557cb
commit c27f74614e
9 changed files with 592 additions and 0 deletions

View File

@@ -7971,3 +7971,27 @@ threshold-checked project metrics and post-25 training-data prerequisites.
**Sprint 25 totals (493-508):** **Sprint 25 totals (493-508):**
- **Steps completed:** 16 - **Steps completed:** 16
- **New tests in this sprint plan:** 180/180 passing - **New tests in this sprint plan:** 180/180 passing
## Post-Sprint 25 Planning Update
Added the next multi-sprint roadmap as standalone plan documents in repo root,
following the same structure pattern as previous sprint plans:
- `sprint26_plan.md` — GUI/UI/UX foundations, docking reliability, visual identity,
interaction-state clarity, and modifier-edge shortcut notation
- `sprint27_plan.md` — constrained constructive editing I (taskitem contracts,
legal operation graph, symbol scope enforcement)
- `sprint28_plan.md` — constrained constructive editing II (legal-choice APIs,
multi-language adapters)
- `sprint29_plan.md` — routing/context/cost discipline for constrained execution
- `sprint30_plan.md` — debugger/runtime observability I (breakpoints, stepping,
stack traces, call stack, locals/watches)
- `sprint31_plan.md` — debugger/runtime observability II (memory reflection,
advanced debug views)
- `sprint32_plan.md` — markdown intake and architect-side taskitem generation
with confidence/ambiguity labeling
- `sprint33_plan.md` — productization, onboarding/value communication,
release hardening and benchmark readiness
These plans intentionally distribute work across multiple sprints (rather than a
single sprint) to preserve implementation quality and maintainability.

116
sprint26_plan.md Normal file
View File

@@ -0,0 +1,116 @@
# Sprint 26 Plan: GUI/UI/UX Foundations
## Context
Sprint 26 is the first focused UX sprint after core infrastructure maturity.
The target is not feature count. The target is interaction clarity and visual
legibility at the level expected from modern professional editors.
Primary goals:
1. Stabilize docking and panel behavior
2. Introduce a coherent visual system (tokens, elevation, borders, contrast)
3. Establish a distinct visual identity: black/white/stone with electric-blue
logic links and "blade edge" highlights
4. Introduce compact modifier-edge shortcut notation
---
## Phase 26a: Interaction and Layout Reliability (Steps 509-514)
### Step 509: Docking Reliability Audit + Deterministic Layout Rules (12 tests)
- Reproduce and eliminate panel drift, hidden tabs, and unexpected undock states
- Add explicit dock-state invariants and recovery paths
- Ensure layout reset is deterministic across startup/session restore
### Step 510: Panel Boundaries, Resizers, and Hit-Target Corrections (12 tests)
- Normalize panel borders, resize affordances, and split-bar hit regions
- Resolve ambiguous click zones where content steals resize focus
- Add regression coverage for mouse + keyboard panel navigation
### Step 511: Interaction State Model (12 tests)
- Define shared state model for hover/focus/active/pressed/disabled
- Replace ad hoc per-widget styling with token-driven state application
- Add contrast checks for every state transition
### Step 512: Window Chrome + Hierarchy Pass (12 tests)
- Introduce consistent hierarchy between work surfaces, tool surfaces, and overlays
- Apply elevation system with subtle shadows + edge highlights
- Ensure modal/non-modal layering semantics are unambiguous
### Step 513: Accessibility Baseline Pass (12 tests)
- Keyboard-only traversal for top-level surfaces and core controls
- Focus-ring visibility and consistency under dark theme
- High-contrast checks for text, iconography, and interactive controls
### Step 514: Phase 26a Integration (8 tests)
- Full docking cycle: open/close/move/reset/restart remains stable
- Interaction states and panel hierarchy render consistently across all major panels
- No regressions in editor typing/focus after layout interaction
---
## Phase 26b: Visual Language and Theming (Steps 515-519)
### Step 515: Theme Token System v2 (12 tests)
- Define semantic color, spacing, radius, border, and elevation tokens
- Support theme derivations without hardcoded widget colors
- Encode high-contrast black/white base with gray-stone layers
### Step 516: Signature Visual Identity Pack (12 tests)
- Add gradient treatment for depth in black surfaces
- Add blade-edge accents for active surfaces and controls
- Add electric-blue accents for long-range logic links and workflow leaps
### Step 517: Control Library Restyle (12 tests)
- Restyle buttons, toggles, tabs, menus, dropdowns, checkboxes
- Clear pressed/depressed depth signals (no ambiguous controls)
- Ensure components render and animate consistently across DPI scales
### Step 518: Icon + Typography Contrast Harmonization (12 tests)
- Harmonize icon stroke weight and text contrast on dark surfaces
- Remove low-information gray-on-black regions
- Improve visual rhythm between dense and sparse panels
### Step 519: Modifier-Edge Shortcut Notation (12 tests)
- Introduce compact glyph system with edge markers on mnemonic letters:
- left edge lit = Ctrl
- right edge lit = Shift
- top edge lit = Super/Win
- bottom edge lit = Alt
- Support combined modifiers in a compact footprint
- Add fallback textual labels for environments that disable glyph rendering
---
## Phase 26c: Final UX Hardening (Steps 520-523)
### Step 520: Completion Overlay UX Hardening (12 tests)
- Eliminate intrusive completion placement over active typing region
- Respect dismissal intent until new semantic trigger appears
- Ensure pointer + keyboard control is predictable
### Step 521: Notification + Status Signaling Refresh (12 tests)
- Distinguish info/warn/error/critical through consistent visual semantics
- Ensure status elements read clearly against dark layers
- Improve temporal behavior (duration, stacking, dismissal)
### Step 522: Cross-Panel Consistency Sweep (12 tests)
- Verify all panels consume shared tokens/state model
- Remove panel-specific style drift
- Enforce spacing/elevation/border consistency checks
### Step 523: Sprint 26 Integration + Summary (8 tests)
- Docking stable, visual language coherent, interaction clarity improved
- Modifier-edge shortcut system functional and space-efficient
- Editor flow no longer blocked by intrusive overlays
---
## Step & Test Summary
| Phase | Steps | Tests | Theme |
|-------|-------|-------|-------|
| 26a | 509-514 | 68 | Docking, layout stability, interaction-state reliability |
| 26b | 515-519 | 60 | Theme system, visual identity, modifier-edge shortcuts |
| 26c | 520-523 | 44 | Overlay/notification hardening and final consistency |
| **Total** | **509-523** | **~172** | 15 steps |

73
sprint27_plan.md Normal file
View File

@@ -0,0 +1,73 @@
# Sprint 27 Plan: Constrained Constructive Editing I
## Context
Sprint 27 begins the reliability path for token-efficient, low-hallucination
execution once taskitems are queued. Markdown-to-taskitem remains a fuzzy
architect problem; taskitem-to-edit becomes a constrained deterministic problem.
Primary goals:
1. Define legal operation surface for each taskitem
2. Restrict symbol/action space to in-scope options
3. Encode contract checks before and after every edit
---
## Phase 27a: Taskitem Constraint Model (Steps 524-528)
### Step 524: Typed Taskitem Contract Schema (12 tests)
- Expand taskitem schema with strict fields: allowed targets, allowed ops,
allowed symbols, forbidden symbols, expected diagnostics deltas
- Reject under-specified taskitems for constrained execution path
### Step 525: Legal Operation Graph (12 tests)
- Build operation graph: insert/update/delete/rename/refactor primitives
- Bind each primitive to language-specific legal contexts
- Enforce op availability by AST node kind
### Step 526: Symbol Scope Extractor (12 tests)
- Build in-scope symbol snapshot per taskitem context
- Provide explicit candidate set to execution engines
- Block unresolved symbol references before apply
### Step 527: Constraint Violation Diagnostics (12 tests)
- New diagnostics for out-of-scope symbol usage and forbidden ops
- Structured machine-readable error payloads for retry/escalation
### Step 528: Phase 27a Integration (8 tests)
- Taskitem with complete constraints routes and executes
- Under-constrained taskitem gets rejected with actionable diagnostics
---
## Phase 27b: Deterministic Apply Guardrails (Steps 529-533)
### Step 529: Pre-Apply Validation Gate (12 tests)
- Validate candidate edit against legal op graph + symbol snapshot
- Reject illegal edits before touching source buffer
### Step 530: Post-Apply Structural Gate (12 tests)
- Re-parse touched region and validate AST integrity
- Validate no unexpected symbol graph drift
### Step 531: Contract Delta Checker (12 tests)
- Compare before/after contract set per taskitem expectations
- Block edits that violate required post-conditions
### Step 532: Retry/Escalation Protocol for Constraint Failures (12 tests)
- Deterministic retry for correctable failures
- Escalate to higher-context worker/human only with full failure packet
### Step 533: Sprint 27 Integration + Summary (8 tests)
- Constrained pipeline prevents out-of-scope edits by construction
- Hallucinated symbol calls fail fast with explicit diagnostics
---
## Step & Test Summary
| Phase | Steps | Tests | Theme |
|-------|-------|-------|-------|
| 27a | 524-528 | 56 | Contract schema, legal ops, scope control |
| 27b | 529-533 | 56 | Guardrails, structural validation, retry/escalation |
| **Total** | **524-533** | **~112** | 10 steps |

70
sprint28_plan.md Normal file
View File

@@ -0,0 +1,70 @@
# Sprint 28 Plan: Constrained Constructive Editing II
## Context
Sprint 28 hardens constrained execution from schema-level guardrails into
practical multi-language constructive editing with legal-choice UIs and
agent-facing operation selectors.
Primary goals:
1. Legal-choice edit UX for agents/humans
2. Multi-language constructive edit adapters
3. Token-budget reductions through constrained option sets
---
## Phase 28a: Legal-Choice Execution Surfaces (Steps 534-538)
### Step 534: Operation Selector API (12 tests)
- Expose only legal operations for active taskitem and AST focus node
- Rank suggestions by expected constraint success
### Step 535: Symbol Selector API (12 tests)
- Expose only in-scope legal symbols with typed role metadata
- Add category filters (function/type/field/module/constant)
### Step 536: Argument Shape Validator (12 tests)
- Validate operation arguments against selected op+symbol contract
- Prevent malformed or semantically invalid argument combinations
### Step 537: Constrained Execution Telemetry (12 tests)
- Log constraint candidate count, selected op path, rejection reasons
- Track token usage deltas vs unconstrained baseline path
### Step 538: Phase 28a Integration (8 tests)
- Agent receives legal-choice menus and executes without out-of-scope references
- Telemetry shows reduced candidate breadth and stable success rate
---
## Phase 28b: Multi-Language Adapters + Quality Gates (Steps 539-543)
### Step 539: C/C++ Constructive Edit Adapter (12 tests)
- Legal op mappings for declarations/definitions/includes/macros
- Header/source boundary-safe operations
### Step 540: Python/TypeScript Constructive Edit Adapter (12 tests)
- Legal op mappings for functions/classes/imports/typing signatures
- Module-level side-effect protections
### Step 541: Rust/Go Constructive Edit Adapter (12 tests)
- Legal op mappings for ownership/concurrency-sensitive constructs
- Borrow/lifetime-unsafe op guardrails
### Step 542: Cross-Language Consistency Gate (12 tests)
- Standardized constraint failures and diagnostics across adapters
- Common fallback behavior on unsupported constructs
### Step 543: Sprint 28 Integration + Summary (8 tests)
- Multi-language constrained constructive editing stable across adapters
- Out-of-scope/hallucinated edits remain blocked across languages
---
## Step & Test Summary
| Phase | Steps | Tests | Theme |
|-------|-------|-------|-------|
| 28a | 534-538 | 56 | Legal-choice APIs, validation, telemetry |
| 28b | 539-543 | 56 | Multi-language adapters and consistency gates |
| **Total** | **534-543** | **~112** | 10 steps |

64
sprint29_plan.md Normal file
View File

@@ -0,0 +1,64 @@
# Sprint 29 Plan: Workflow Intelligence + Cost Discipline
## Context
Sprint 29 tightens orchestration intelligence around constrained editing:
better routing, better context bundles, and explicit cost-control policies.
Primary goals:
1. Context width minimization without quality regression
2. Routing confidence calibration for constrained mode
3. Cost policy enforcement and optimization feedback
---
## Phase 29a: Routing and Context Optimization (Steps 544-548)
### Step 544: Constrained Routing Ruleset Extension (12 tests)
- Add constrained-mode routing policy variants
- Promote deterministic/template paths when legal-choice confidence is high
### Step 545: Context Bundle Minimizer (12 tests)
- Build minimal sufficient context bundles per taskitem contract
- Remove irrelevant file/project context from narrow operations
### Step 546: Confidence Calibration for Constrained Paths (12 tests)
- Calibrate routing confidence with historical constraint outcomes
- Penalize paths with repeated post-apply failures
### Step 547: Cost Policy Guard (12 tests)
- Enforce per-step and per-workflow token ceilings
- Require rationale/escalation when exceeding policy
### Step 548: Phase 29a Integration (8 tests)
- Lower context budgets with maintained pass rates
- Cost guard blocks runaway orchestration paths
---
## Phase 29b: Optimization Feedback Loops (Steps 549-553)
### Step 549: Suggestion Engine for Cost Reductions (12 tests)
- Suggest template substitution, batching, and context narrowing opportunities
### Step 550: Worker Efficiency Dashboard Data Model (12 tests)
- Aggregate completion/cost/rejection/latency by worker and task class
### Step 551: Review-Gate Policy Refinement (12 tests)
- Reduce unnecessary human escalations while preserving safety/quality
### Step 552: Cost vs Quality Regression Suite (12 tests)
- Assert quality does not regress as optimization policies tighten
### Step 553: Sprint 29 Integration + Summary (8 tests)
- Routing intelligence and cost controls operate as a coherent policy layer
---
## Step & Test Summary
| Phase | Steps | Tests | Theme |
|-------|-------|-------|-------|
| 29a | 544-548 | 56 | Routing/context/cost policy optimization |
| 29b | 549-553 | 56 | Feedback loops and quality-preserving optimization |
| **Total** | **544-553** | **~112** | 10 steps |

63
sprint30_plan.md Normal file
View File

@@ -0,0 +1,63 @@
# Sprint 30 Plan: Debugger + Runtime Observability I
## Context
Sprint 30 starts runtime observability features expected in full editors:
breakpoints, stepping, stack frames, locals, watches, and trace surfaces.
Primary goals:
1. Core debugger control plane
2. Runtime state inspection surfaces
3. Integration with existing workflow/task model
---
## Phase 30a: Debug Control Plane (Steps 554-558)
### Step 554: Debug Session Model (12 tests)
- Session lifecycle: start/attach/pause/resume/stop
- Multi-target and per-buffer debug context support
### Step 555: Breakpoint System (12 tests)
- Line breakpoints, conditional breakpoints, hit-count breakpoints
- Enable/disable persistence and reconciliation on file edits
### Step 556: Step Engine (12 tests)
- Step-into, step-over, step-out, continue semantics
- Deterministic state transitions and UI command mapping
### Step 557: Exception + Stack Trace Capture (12 tests)
- Structured exception events and stack traces
- Link stack frames to editor navigation anchors
### Step 558: Phase 30a Integration (8 tests)
- Full breakpoint-to-step-to-exception cycle executes reliably
---
## Phase 30b: Runtime Inspection Surfaces (Steps 559-563)
### Step 559: Call Stack and Frame Inspector (12 tests)
- Frame navigation and variable scope mapping
### Step 560: Locals + Watches Panel Data Model (12 tests)
- Type-aware variable display, watch expression lifecycle
### Step 561: Trace Timeline Model (12 tests)
- Event timeline for pause/step/exception transitions
### Step 562: Workflow-Aware Debug Hooks (12 tests)
- Attach debug sessions to active workflow items and diagnostics
### Step 563: Sprint 30 Integration + Summary (8 tests)
- Debugger baseline reaches practical daily-use utility
---
## Step & Test Summary
| Phase | Steps | Tests | Theme |
|-------|-------|-------|-------|
| 30a | 554-558 | 56 | Debug session, breakpoints, stepping, stack traces |
| 30b | 559-563 | 56 | Runtime inspectors and workflow integration |
| **Total** | **554-563** | **~112** | 10 steps |

59
sprint31_plan.md Normal file
View File

@@ -0,0 +1,59 @@
# Sprint 31 Plan: Debugger + Runtime Observability II
## Context
Sprint 31 extends debugger capabilities with memory reflection,
advanced runtime views, and performance-aware introspection.
Primary goals:
1. Memory reflection as first-class editor capability
2. Advanced runtime introspection
3. Better debugging ergonomics for complex systems
---
## Phase 31a: Memory Reflection Core (Steps 564-568)
### Step 564: Memory Snapshot Model (12 tests)
- Structured snapshot schema for stack, heap regions, and references
### Step 565: Memory Inspector UI Model (12 tests)
- Typed renderers for primitives, pointers/references, containers, structs
### Step 566: Allocation/Ownership Trace Hooks (12 tests)
- Allocation timeline and ownership transition markers
### Step 567: Leak/Corruption Signal Bridge (12 tests)
- Integrate leak/corruption signals into diagnostics + debug panes
### Step 568: Phase 31a Integration (8 tests)
- Memory reflection workflow: snapshot -> inspect -> correlate with stack/debug state
---
## Phase 31b: Advanced Debug Views (Steps 569-573)
### Step 569: Disassembly + Register View Baseline (12 tests)
- Optional architecture-aware low-level inspection surface
### Step 570: Watch Expression Evaluator Hardening (12 tests)
- Safe evaluation boundaries and timeout protections
### Step 571: Time-Travel Debug Event Buffer (12 tests)
- Bounded historical state replay for recent execution steps
### Step 572: Performance Probe Overlay (12 tests)
- Inline timing/hotspot metadata tied to debug pauses
### Step 573: Sprint 31 Integration + Summary (8 tests)
- Memory reflection + advanced views usable without destabilizing core editor flow
---
## Step & Test Summary
| Phase | Steps | Tests | Theme |
|-------|-------|-------|-------|
| 31a | 564-568 | 56 | Memory reflection core |
| 31b | 569-573 | 56 | Advanced runtime debug views |
| **Total** | **564-573** | **~112** | 10 steps |

63
sprint32_plan.md Normal file
View File

@@ -0,0 +1,63 @@
# Sprint 32 Plan: Architect Intake + Markdown-to-Taskitem
## Context
Sprint 32 addresses the fuzzy intake side explicitly:
high-context problem descriptions (markdown PRDs/specs) into structured
project plans and taskitems for constrained execution.
Primary goals:
1. Robust markdown intake and requirement extraction
2. Architect-level planning outputs with review controls
3. Reliable taskitem generation with explicit confidence and uncertainty labels
---
## Phase 32a: Markdown Intake Pipeline (Steps 574-578)
### Step 574: Markdown Spec Parser (12 tests)
- Parse sections, goals, constraints, dependencies, acceptance criteria
- Preserve traceability back to source section anchors
### Step 575: Requirement Normalization and Conflict Detection (12 tests)
- Normalize ambiguous language into structured requirement records
- Detect contradictory constraints and flag for architect review
### Step 576: Scope and Milestone Decomposer (12 tests)
- Convert requirements into epics/milestones/workstreams
- Include uncertainty scoring per decomposed item
### Step 577: Architect Review Surface for Intake (12 tests)
- Approve/modify/reject extracted constraints before task generation
### Step 578: Phase 32a Integration (8 tests)
- Markdown spec -> normalized plan with conflict signals and review traceability
---
## Phase 32b: Taskitem Generation for Constrained Execution (Steps 579-583)
### Step 579: Taskitem Generator v2 (12 tests)
- Generate taskitems with legal-op prerequisites and dependency graph hints
### Step 580: Taskitem Confidence + Ambiguity Annotation (12 tests)
- Attach confidence and ambiguity fields that drive routing/escalation
### Step 581: Acceptance-Criteria Binding (12 tests)
- Bind each taskitem to explicit acceptance checks and test skeletons
### Step 582: Intake-to-Queue Simulation Harness (12 tests)
- End-to-end harness from markdown ingestion to queue-ready constrained taskitems
### Step 583: Sprint 32 Integration + Summary (8 tests)
- Intake pipeline produces high-quality architect-reviewed task queues
---
## Step & Test Summary
| Phase | Steps | Tests | Theme |
|-------|-------|-------|-------|
| 32a | 574-578 | 56 | Markdown intake and requirement normalization |
| 32b | 579-583 | 56 | Taskitem generation with constrained execution metadata |
| **Total** | **574-583** | **~112** | 10 steps |

60
sprint33_plan.md Normal file
View File

@@ -0,0 +1,60 @@
# Sprint 33 Plan: Productization + Competitive Readiness
## Context
Sprint 33 turns the technical stack into a coherent product experience:
clear value communication, production hardening, and benchmarked differentiation.
Primary goals:
1. Make Whetstone's MCP/workflow advantage obvious in-editor
2. Harden operational quality and release ergonomics
3. Prepare enterprise-ready demonstration and onboarding flows
---
## Phase 33a: Product Experience and Positioning (Steps 584-588)
### Step 584: Value-Forward Onboarding Flow (12 tests)
- First-run flow that showcases MCP tool depth and constrained execution strengths
### Step 585: Workflow Visualization 2.0 (12 tests)
- Clear long-range dependency/logic links with electric-blue visual language
- Explain routing decisions and review gates in plain language
### Step 586: Capability Discovery Panels (12 tests)
- Surface tool categories, operation counts, and contextual recommendations
### Step 587: Guided Architect-to-Execution Demo Mode (12 tests)
- Demonstrate intake -> task queue -> constrained edits -> verification loop
### Step 588: Phase 33a Integration (8 tests)
- Users can immediately identify Whetstone's distinct strengths on first use
---
## Phase 33b: Release and Operational Hardening (Steps 589-593)
### Step 589: Release Readiness Gate Pack (12 tests)
- Consolidated go/no-go checks for UX, runtime, regression, and telemetry
### Step 590: Crash + Recovery Reliability Sweep (12 tests)
- Crash-safe session recovery and workflow continuity guarantees
### Step 591: Benchmark and Comparison Harness (12 tests)
- Internal benchmark scripts for throughput, reliability, and token efficiency
### Step 592: Documentation + Operator Playbooks (12 tests)
- Architecture/operator docs for deployments, debugging, and support workflows
### Step 593: Sprint 33 Integration + Program Summary (8 tests)
- Final integration proving editor maturity + constrained execution advantage
---
## Step & Test Summary
| Phase | Steps | Tests | Theme |
|-------|-------|-------|-------|
| 33a | 584-588 | 56 | Product UX, workflow communication, onboarding |
| 33b | 589-593 | 56 | Release hardening, recovery, benchmark/readiness |
| **Total** | **584-593** | **~112** | 10 steps |