Repository navigation
Add Backlog state and maturity-tag spec roadmapping (#56) - #326
zwanski-start wants to merge 3 commits into
Conversation
AutoForgeAI#56) - api/roadmap.py: maturity tags (alpha/limited_beta/beta), configurable ordering, and Backlog -> Pending ready checks - Feature model: backlog, maturity, spec_notes columns + migration - Orchestrator/MCP/resolver: Backlog features are never resumed, claimed or scheduled; ready features sort by maturity tag, then scheduling score - REST: spec-review, backlog and promote endpoints (409 with failing checks unless force=true), backlog bucket in list, backlog graph status, maturity_order global setting - Tests in test_roadmap.py Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…geAI#56) - Backlog column on the Kanban board with ready-check progress - Maturity badges on cards, maturity filter with counts and a Pending build-queue breakdown by tag - Spec Review panel in the feature modal: tag, notes, ready checks, promote (with explicit override) and move to Backlog - Maturity tag + Add to Backlog option when creating features - Maturity priority order in Settings; backlog status in the graph Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
🔍 QA report: ❌ FailedTester: Guido (cubefarm agent, in a fresh session) · Round: 1 · Author: Ken The backend is solid. The Backlog state, ready checks with a 409 or a forced override, maturity ordering in the orchestrator and MCP queue, the legacy DB migration and all REST validation behave as described, and the Backlog column, badges, filter and Spec Review panel work in the browser. However, the 'Settings: Maturity Priority reorder list' was added to SettingsModal.tsx, which nothing renders: the sidebar Settings link and the ',' shortcut open SettingsView. So the configurable maturity ordering can't be reached from the UI at all, only through PATCH /api/settings. Fix that and this is ready to pass.
🧪 Commands run
🔧 What needs fixingThe Maturity Priority reorder control is in ui/src/components/SettingsModal.tsx, but no part of the app renders SettingsModal. The settings route renders ui/src/components/views/SettingsView.tsx (see ui/src/components/layout/ContentArea.tsx:38, the Sidebar Settings link and the ',' shortcut in AppContext.tsx:370). Add the same 'Maturity Priority' block (the ordered list with up/down buttons, data-testid="maturity-order", and the handleMaturityMove handler that calls updateSettings.mutate({ maturity_order })) to SettingsView.tsx, inside its existing settings card. Either remove the copy from the unused modal or keep both. Then confirm in the browser that clicking Settings shows the list and that moving a tag changes GET /api/settings maturity_order. Optional: normalize maturity_order entries in SettingsUpdate (for example 'Limited Beta'), as the feature endpoints already do. No browser screenshots were taken in this round. Posted by cubefarm · sent back to the developer for fixes |
The reorder control lived only in SettingsModal, which nothing renders; the sidebar Settings link and ',' shortcut open SettingsView. Extract it into MaturityOrderSetting and render it in both. Also normalize maturity_order entries (e.g. 'Limited Beta') in SettingsUpdate. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
🔍 QA report: ✅ PassedTester: Guido (cubefarm agent, in a fresh session) · Round: 2 · Author: Ken Round 2 fixes last round's blocking problem. The Maturity Priority reorder list is now a shared MaturityOrderSetting component rendered in SettingsView (the screen the sidebar link and ',' shortcut open). Reordering in the browser updates and keeps GET /api/settings maturity_order. The optional cleanup also landed: SettingsUpdate now accepts input like 'Limited Beta' and still rejects bad orders with 422, with a new unit test. Tests, ruff, mypy (no change from master), the UI build and lint all pass, and a smoke test of the board, promotion and graph found no regressions.
🧪 Commands run
No browser screenshots were taken in this round. Posted by cubefarm · merges automatically once GitHub's checks pass |
Features can be parked in a Backlog lane that agents never pick up, and get a spec review with a maturity tag (alpha / limited beta / beta) plus notes. Promotion to Pending runs ready checks (description, test steps, maturity tag, no dependency in the Backlog) unless the user overrides them. Ready features are scheduled by maturity tag in the order set in Settings, then by dependency score. Adds backlog, maturity and spec_notes columns (migration with defaults; tested on copies of real projects: idempotent, data unchanged, pre-migration code still reads and inserts). Adaptations on integration: - merged with the Manual Testing lane, test evidence, the live browser view and the 409 refusal handling from earlier phases (both lanes shown, the board grid adapts to 4-6 columns); - Backlog features stay out of progress totals (progress.count_passing_tests feeds the WebSocket progress, project stats and "all features complete"; feature_get_stats reports them apart) and out of the blocked list; - a pending feature that depends on a Backlog feature now stops the orchestrator with "depends on Backlog feature(s) #N; promote them to Pending", instead of listing the Backlog feature as "ready but not started" and its dependent as waiting on unfinished work; the completion message says how many features stay in the Backlog; - the migration also creates the backlog index the model declares; - new endpoints keep the 409 for a refused project path. Integrates AutoForgeAI#326 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AeH26pcsqoxPb3CDs8g1VN
Closes #56
Adds a Backlog state for work that isn't ready yet, and a Spec Review step that gives each feature a maturity tag (
alpha/limited_beta/beta). The tag decides which build-ready work the agents pick up first.Behavior
get_ready_features, resume, batch chain extension,start_feature[_batch]), the resolver'sget_ready_features, and the MCPfeature_get_ready/feature_claim_and_get/feature_mark_in_progress(atomicUPDATE … AND COALESCE(backlog,0)=0) all skip Backlog features. Backlog items also don't stop a run from counting as complete.force: true, which is the explicit human override.API
POST /api/projects/{p}/features/{id}/spec-review{maturity, notes?}POST …/{id}/backlog: rejected for done (400) or in-progress (409) featuresPOST …/{id}/promote{force?: bool}backlog,maturityandspec_notes. PATCH takesmaturityandspec_notes; sending explicitnullclears them. The tag accepts input like "Limited Beta".backlog,maturity,spec_notes,readiness[]andready. The list response has abacklogbucket, and the graph nodes have abacklogstatus plusmaturity.maturity_order(GET/PATCH/api/settings; it must be a permutation of the three tags or the request returns 422).UI
maturityandspec_notes. MCPfeature_get_by_idalready returns them throughto_dict().Verification
python -m pytest test_roadmap.py(new): 17 passed. Covers the helpers, ready checks, queue exclusion and ordering, the DB migration from a legacy schema, all REST endpoints, and the MCP claim guardrail.ruff check .is clean.mypyreports no new errors (the remaining 24 are all in files this PR doesn't touch).test_security.py,test_security_integration.py,test_dependency_resolver.py,test_client.py,test_rate_limit_utils.pyandtest_ws_security.pyall pass.test_devserver_security.pyhas 21 failures that also happen on unmodified master and are not related to this PR.npm run lintshows 0 errors (the warnings were already there).npm run buildpasses.Assumptions / scope notes
force=true. The UI asks for confirmation first, and the server logs the override.maturity_orderonce at startup, so a change applies on the next agent start (the Settings text says this). MCPfeature_get_readyreads it on every call.AutoForgeAI/autoforge(403 for this account), so this PR comes from thezwanski-startfork.🤖 Generated with Claude Code