Add sprint 26-33 roadmap plans and progress update
This commit is contained in:
24
progress.md
24
progress.md
@@ -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
116
sprint26_plan.md
Normal 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
73
sprint27_plan.md
Normal 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
70
sprint28_plan.md
Normal 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
64
sprint29_plan.md
Normal 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
63
sprint30_plan.md
Normal 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
59
sprint31_plan.md
Normal 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
63
sprint32_plan.md
Normal 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
60
sprint33_plan.md
Normal 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 |
|
||||||
Reference in New Issue
Block a user