docs(specs): ops-specs-features — port attune-gui spec UI to attune ops (gated draft)#230
Merged
Merged
Conversation
…ps (gated) attune-gui has a working spec-handling surface (federated multi- root listing, status flip, phase bootstrap) that attune ops lacks. Side-by-side use today requires context switching between two dashboards. Spec proposes porting a SUBSET to attune ops: - IN: list, status flip, read-only drill-in - OUT: spec creation, phase bootstrap, editor — these stay in attune-gui and the /spec slash command The spec's most load-bearing element is its execution gate: Phase 1 doesn't start until #212 ships clean, #227/#228 land, no critical open ops bugs, Probe C Phase 4 settles. Per Patrick's explicit "don't add features until existing ones work well" position. Decisions.md: problem, port/no-port scope, alternatives, acceptance criteria. Tasks.md: Phase 0 gate (the contract), Phase 1 read-side, Phase 2 write-side (status flip), Phase 3 frontend, Phase 4 observe + adjust. Phase 4 explicitly questions whether Phase 1 was enough before expanding scope. Pattern-matches the recent specs (probe-c, larger-runners) in shape and gating discipline. Status: Draft.
github-actions
Bot
added
the
documentation
Patrick noted the "1 week of green CI" criterion was arbitrary
("based on a one-week guess"). Replaced with:
3 consecutive green CI runs on main + no new CI-fix PRs
opened during that window
Measurable, evidence-based, not calendar-based. Could clear in
a day or a week — whichever demonstrates stability via data.
Updates both decisions.md (criterion #1 of the execution gate)
and tasks.md (Phase 0 checklist item).
Per Patrick's approval. Status flipped from Draft → Approved on both decisions.md (existing Status field updated) and tasks.md (Status field added for symmetry). Execution is still gated on Phase 0 conditions; "Approved" means the design is signed off and the work CAN proceed when the gate clears, not that the work starts now. Matches the spec status convention from attune-gui's cowork_specs.py: draft / in-review / approved / complete / done
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
silversurfer562
added a commit
that referenced
this pull request
May 11, 2026
Per Patrick's call: trim attune ops nav to the tabs people actually use. The Memory and Releases tabs both have low daily utility, and Releases is strictly redundant with Home's "Family snapshot" panel. What's removed: - /memory route + memory.html template - /releases route + releases.html template - data.list_memory_topics() helper + MemoryEntry dataclass (both unused after the route removal) - Nav entries for Memory and Releases in server.py - "memory, releases" mention in home.html hero subtitle What's kept: - /api/info still surfaces version data via family_versions() - Home "Family snapshot" panel still lists installed family packages — that's where the Releases info lives - The Releases KPI tile on Home now anchors to the in-page #family-snapshot section instead of /releases - attune memory CLI commands are unaffected (this is just dashboard UI) Tests updated: - test_smoke.py parametrized page list trimmed to workflows/telemetry/health - New test_removed_pages_404 asserts /memory and /releases return 404 (regression catch if someone re-adds them carelessly) Pairs naturally with the (gated, approved) spec to add a Specs tab in #230 — net effect of both: 6 tabs → 5 tabs but all 5 are high-utility for the spec-driven workflow.
silversurfer562
added a commit
that referenced
this pull request
May 11, 2026
…235) Patrick prioritized this spec for upcoming work. The original Phase 0 gate (written defensively last night during the CI tar-pit) was over-correlated to unrelated CI work. Tightened to what actually matters for ops-specs-features. Dropped: - "3 consecutive green CI runs on main" — replaced with "most-recent merge cycle's settled run shows only known pre-existing failures." Reason: post-Probe-C the steady state is stable; the strict 3-in-a-row was over-corrective. Recent main runs are mostly cancelled by concurrency from rapid merges, not by failure. - "Probe C Phase 4 settled" — Phase 4 (restore -n auto parallel xdist) is a CI optimization orthogonal to ops-specs-features. The two specs share no code surface; gating ops-specs-features on Phase 4 was defensive coupling without justification. Kept (still binary, still load-bearing): - #212 merged + main CI stable on the settled run ✅ - #227 + #228 merged ✅ - No critical open ops issues ✅ - #226 larger runners (optional) ✅ Status flipped: "Approved (gated)" → "Approved & Prioritized (2026-05-11) — gate relaxed; ready when next main CI settles." When the next main CI settles cleanly (or only the known pre-existing failures), Phase 1 can start.
5 tasks
silversurfer562
added a commit
that referenced
this pull request
May 11, 2026
Adds PUT /api/specs/{slug}/{phase}/status to flip the **Status** line
in a phase file. Mirrors attune-gui semantics; rejected in --read-only
mode. Atomic write via tempfile+os.replace. 16 new tests, all passing.
Closes Phase 2 of #230 (ops-specs-features). Frontend in Phase 3.
Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
10 tasks
silversurfer562
added a commit
that referenced
this pull request
May 11, 2026
Adds the Specs tab to the ops dashboard with status-flip dropdowns and per-spec drill-in. Closes Phase 3 of #230. Components: - New nav entry "Specs" between Workflows and Telemetry - /specs page: table of all specs across configured roots with a 4-column status grid (decisions, requirements, design, tasks). Statuses render as <select> in writeable mode, plain chips in --read-only mode - /specs/{slug} page: drill-in showing each phase file's full body with status chips inline - specs.js: optimistic UI for status flip with rollback on server error; PUTs to /api/specs/{slug}/{phase}/status from Phase 2 - main.css: chip-styled <select>, flash feedback (ok/err outline), read-only spec body pre-block Tests: 17 new tests (dashboard routes), 77 total in tests/unit/ops/. Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
silversurfer562
added a commit
that referenced
this pull request
May 11, 2026
* feat(ops): Phase 3 of ops-specs-features — Specs tab frontend Adds the Specs tab to the ops dashboard with status-flip dropdowns and per-spec drill-in. Closes Phase 3 of #230. Components: - New nav entry "Specs" between Workflows and Telemetry - /specs page: table of all specs across configured roots with a 4-column status grid (decisions, requirements, design, tasks). Statuses render as <select> in writeable mode, plain chips in --read-only mode - /specs/{slug} page: drill-in showing each phase file's full body with status chips inline - specs.js: optimistic UI for status flip with rollback on server error; PUTs to /api/specs/{slug}/{phase}/status from Phase 2 - main.css: chip-styled <select>, flash feedback (ok/err outline), read-only spec body pre-block Tests: 17 new tests (dashboard routes), 77 total in tests/unit/ops/. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> * fix(tests): remove dead patch.dict scaffolding causing Py 3.10 flake The `patch.dict("attune.routing.chain_executor.__dict__", {})` block in `test_value_error_in_comparison_returns_false` is dead code — body is `pass` and the dict to patch in is empty. The actual test assertion at the end of the function (`_evaluate_condition("missing_var > 5", {})`) exercises the same code path without needing the patch. The dead block was failing on Py 3.10 only because mock resolves the parent module via `getattr(attune.routing, 'chain_executor')` — on 3.10 that attribute isn't reliably bound even though `attune/routing/__init__.py` imports from `.chain_executor`. The actual TypeError-from-op_func branch is covered by `test_operator_eval_typeerror_caught` directly below it (uses a custom RaisingEq class — no patch.dict needed). Net: -22 LOC, identical coverage, clears the recurring Py 3.10 flake that's been failing every PR's matrix run. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Port a subset of attune-gui's spec-handling features (federated listing, status flip, read-only drill-in) to attune ops as a new
Specstab.This is a DRAFT spec with an explicit execution gate. No code lands until the gate clears.
Why now (the spec, not the build)
Patrick: "I don't want to add features until we get all of our existing ones working well." Exactly right — which is also exactly why the spec is the right artifact to write now:
Scope (tight)
Port:
decisions.md/tasks.md/design.md/requirements.md)Do NOT port:
/specskill already covers thisExecution gate (Phase 0)
Phase 1 doesn't start until all of:
ops-labeled issuesTwo files
docs/specs/ops-specs-features/decisions.mddocs/specs/ops-specs-features/tasks.md🤖 Generated with Claude Code