- commit
- 7fa817e87e8d1da77f342f4b1522d1552cd39a46
- parent
- e5a66d83731980db24a645b6092ed22ef9e8a96c
- author
- dami etoile <dami.etoile@gmail.com>
@@ -1,61 +1,47 @@
1-# Board Search and Filter Specification1+# Board Search and Filter Delta22 3-## Purpose4-5-Make the kanban board usable at scale by adding text search and archived column visibility controls.6-7-## Requirements3+## ADDED Requirements84 95 ### Requirement: Text filter on board10-11-The board must provide a text input that filters cards across all columns by title, name, or token.6+The board SHALL provide a text input that filters cards across all columns by title, name, or token.127 138 #### Scenario: Filter by title14-159 - **GIVEN** the board has changes with known titles1610 - **WHEN** the user types a title substring into the filter input17-- **THEN** only cards whose title contains the substring (case-insensitive) are shown11+- **THEN** only cards whose title contains the substring case-insensitively are shown1812 1913 #### Scenario: Filter by token20-2114 - **GIVEN** the board has changes with tokens22-- **WHEN** the user types a token (e.g. `os_a1b2c3`) into the filter input15+- **WHEN** the user types a token such as `os_a1b2c3` into the filter input2316 - **THEN** only cards whose token contains the substring are shown2417 2518 #### Scenario: Empty filter shows all26-2719 - **GIVEN** the filter input has text2820 - **WHEN** the user clears the filter input29-- **THEN** all cards in all columns are shown21+- **THEN** all cards in all visible columns are shown3022 3123 #### Scenario: No matches32-3324 - **GIVEN** the filter input has text that matches no cards3425 - **WHEN** the board renders35-- **THEN** a "no matches" empty state is shown in place of the columns26+- **THEN** a no-matches empty state is shown instead of an empty set of columns3627 3728 ### Requirement: Archived column toggle38-39-The board must provide a toggle to show or hide the archived column.29+The board SHALL provide a toggle to show or hide the archived column while keeping archived cards visible by default.4030 4131 #### Scenario: Hide archived42-4332 - **GIVEN** the board is showing the archived column44-- **WHEN** the user clicks the archived toggle to hide33+- **WHEN** the user disables the archived toggle4534 - **THEN** the archived column is not rendered4635 47-#### Scenario: Show archived (default)48-36+#### Scenario: Show archived by default4937 - **GIVEN** the board is loaded for the first time50-- **WHEN** the archived column is evaluated51-- **THEN** the archived column is visible by default38+- **WHEN** the archived column visibility is evaluated39+- **THEN** the archived column is visible5240 5341 ### Requirement: Hash deep-link bypass54-55-The filter must not prevent hash-deep-linked items from opening.42+The board filter SHALL NOT prevent hash-deep-linked items from opening.5643 5744 #### Scenario: Hash token with active filter58-5945 - **GIVEN** the filter input has text that would hide a specific card6046 - **WHEN** a hash token matching that card is present in the URL6147 - **THEN** the card's detail dialog opens regardless of the filter@@ -1,85 +1,62 @@
1-# Bundled OpenSpec Workflow Skills + CLI Passthrough Specification1+# Bundled OpenSpec Workflow Skills and CLI Passthrough Delta22 3-## Purpose3+## ADDED Requirements44 5-Bundle upstream OpenSpec workflow skills as Hermes plugin skills and add an `openspec_cli` passthrough tool, creating a clean layer separation between workflow prompts (skills), CLI access, ad-hoc query tools, and the dashboard.6-7-## Requirements8-9-### Requirement: Bundle 11 upstream workflow skills10-11-The plugin must bundle all 11 upstream OpenSpec workflow skills as Hermes plugin skills, registered via `ctx.register_skill()`.5+### Requirement: Bundle upstream workflow skills6+The plugin SHALL bundle all upstream OpenSpec workflow skills as Hermes plugin skills and register them during plugin load.127 138 #### Scenario: Skills registered on plugin load14-159 - **GIVEN** the plugin is installed and enabled1610 - **WHEN** Hermes starts and calls `register(ctx)`17-- **THEN** all 11 skills (`openspec-propose`, `openspec-explore`, `openspec-apply-change`, `openspec-archive-change`, `openspec-new-change`, `openspec-continue-change`, `openspec-ff-change`, `openspec-verify-change`, `openspec-sync-specs`, `openspec-bulk-archive-change`, `openspec-onboard`) are registered and appear in `hermes skills list`18-19-#### Scenario: Skill content matches upstream11+- **THEN** all bundled workflow skills are registered and appear in the Hermes skill catalog2012 13+#### Scenario: Skill content matches upstream format2114 - **GIVEN** the bundled skill files exist in `skills/<name>/SKILL.md`22-- **WHEN** the skill content is compared to the upstream `generateSkillContent()` output23-- **THEN** the YAML frontmatter and instructions body match the upstream format without modification24-25-#### Scenario: Agent auto-loads skill on intent match26-27-- **GIVEN** the `openspec-propose` skill is registered28-- **WHEN** the user says "propose a change for dark mode"29-- **THEN** the agent loads the `openspec-propose` skill and follows its workflow15+- **WHEN** a contributor inspects a bundled skill16+- **THEN** the skill uses upstream OpenSpec-style YAML frontmatter and workflow instructions without being rewritten around plugin-specific tool shapes3017 3118 #### Scenario: Skills call CLI directly via terminal19+- **GIVEN** an upstream workflow skill is loaded in a session20+- **WHEN** the skill instructs the agent to run an OpenSpec workflow command21+- **THEN** the agent may execute the OpenSpec CLI directly rather than routing the workflow through plugin wrapper tools3222 33-- **GIVEN** an upstream skill is loaded in a session34-- **WHEN** the skill instructs the agent to run `openspec new change "<name>"`35-- **THEN** the agent executes the command via the `terminal` tool, not via plugin wrapper tools36-37-### Requirement: openspec_cli passthrough tool38-39-The plugin must provide an `openspec_cli` tool that runs the `openspec` CLI binary and returns raw output.23+### Requirement: OpenSpec CLI passthrough tool24+The plugin SHALL provide an `openspec_cli` passthrough tool that runs the OpenSpec CLI binary and returns raw command output.4025 4126 #### Scenario: Tool appears when CLI is installed42-4327 - **GIVEN** the `openspec` binary is available on PATH or via `OPENSPEC_BIN`4428 - **WHEN** the plugin registers tools45-- **THEN** `openspec_cli` appears in the agent's tool list29+- **THEN** `openspec_cli` is available in the agent tool list4630 4731 #### Scenario: Tool hidden when CLI is not installed48-4932 - **GIVEN** the `openspec` binary is not available5033 - **WHEN** the plugin registers tools51-- **THEN** `openspec_cli` does not appear in the agent's tool list34+- **THEN** `openspec_cli` is not exposed5235 5336 #### Scenario: JSON output mode54-5537 - **GIVEN** the `openspec` CLI is installed56-- **WHEN** the agent calls `openspec_cli` with `command: "status --change my-change"` and `json_output: true`57-- **THEN** the tool runs `openspec status --change my-change --json` and returns the raw JSON output from the CLI38+- **WHEN** the agent calls `openspec_cli` with a command and `json_output: true`39+- **THEN** the tool runs the command with JSON output enabled and returns the raw CLI JSON payload5840 5941 #### Scenario: Raw output mode60-6142 - **GIVEN** the `openspec` CLI is installed62-- **WHEN** the agent calls `openspec_cli` with `command: "list"` and `json_output: false`63-- **THEN** the tool runs `openspec list` (without `--json`) and returns the raw text output43+- **WHEN** the agent calls `openspec_cli` with `json_output: false`44+- **THEN** the tool runs the command without forcing JSON output and returns the raw text payload6445 6546 #### Scenario: Workdir support66-6747 - **GIVEN** a project at a specific path68-- **WHEN** the agent calls `openspec_cli` with `workdir: "/path/to/project"`69-- **THEN** the CLI command runs with that path as the working directory48+- **WHEN** the agent calls `openspec_cli` with that workdir49+- **THEN** the CLI command runs in that directory7050 7151 ### Requirement: Layer separation documentation72-73-The plugin must include documentation explaining the boundary between skills, CLI, plugin tools, and dashboard.52+The plugin SHALL include documentation explaining the boundary between bundled workflow skills, CLI access, plugin tools, and the dashboard.7453 7554 #### Scenario: Layer doc exists76-77-- **GIVEN** the plugin is installed55+- **GIVEN** the plugin repository is checked out7856 - **WHEN** a contributor reads `docs/layers.md`79-- **THEN** the doc explains that skills call the CLI directly via terminal, plugin tools return different JSON shapes, and the two coexist by design57+- **THEN** the document explains that workflow skills call the OpenSpec CLI directly, plugin tools return plugin-specific JSON shapes, and both interfaces coexist by design8058 8159 #### Scenario: README references layer doc82-8360 - **GIVEN** the plugin README is read8461 - **WHEN** the reader looks for architecture information85-- **THEN** the README links to `docs/layers.md` and mentions the layer architecture62+- **THEN** the README links to `docs/layers.md` and summarizes the layer architecture@@ -0,0 +1,34 @@
1+## Context2+3+The dashboard spec browser has several wide surfaces:4+5+- top-level toolbar and view-mode controls6+- `os-specs-grid` two-column file-list/detail layout7+- side-by-side diff columns8+- long spec paths and requirement/scenario text9+- modal wrappers used by change/spec detail views10+11+These are fine on desktop but break narrow screens by creating horizontal overflow or cramped controls.12+13+## Decisions14+15+### Decision 1: Collapse the spec browser grid on narrow screens16+17+Use a single-column layout for the spec browser below the mobile breakpoint. The file list becomes a horizontal strip so the selected spec remains close to the detail pane without requiring a full vertical list before the content.18+19+### Decision 2: Stack diff columns on mobile20+21+Side-by-side content is a desktop affordance. On mobile, before/after columns and scenario-level before/after blocks stack vertically to preserve readable line lengths.22+23+### Decision 3: Wrap long identifiers and text24+25+Spec paths, requirement names, scenario names, step text, and card titles wrap with `overflow-wrap: anywhere` where needed. This prevents one long token or path from pushing the entire page wider than the viewport.26+27+### Decision 4: Keep controls available28+29+Mode toggles and toolbar groups wrap or become horizontally scrollable instead of disappearing. Users should not lose semantic/side-by-side/raw review capability just because they are on mobile.30+31+## Risks / Trade-offs32+33+- Horizontal file-list scrolling is still a scroll surface, but it is bounded to the list rather than the entire page.34+- Side-by-side diff mode is no longer visually side-by-side on mobile; the semantic meaning is preserved by stacked before/after content.@@ -0,0 +1,18 @@
1+# Mobile-friendly spec layout2+3+## Summary4+5+Make the dashboard spec browser and spec-diff views usable on narrow mobile screens. The layout should collapse wide desktop grids, keep controls reachable, and prevent long spec paths or requirement text from forcing horizontal page overflow.6+7+## Motivation8+9+The spec browser was designed as a desktop two-pane view: file list on the left, detail pane on the right, with optional side-by-side diff columns. On phones this creates unreadable horizontal overflow. The latest dashboard layout changes add responsive CSS for the spec browser, semantic diff view, modal body, and related controls; this change records the expected behavior in OpenSpec.10+11+## Design12+13+At narrow viewport widths, the spec browser uses a single-column detail layout with a horizontally scrollable file strip. Diff columns stack vertically, toolbar/control groups wrap or scroll horizontally, and long paths/requirement text wrap safely. Modal padding and body height shrink to preserve usable screen space.14+15+## Alternatives considered16+17+- **Hide diff modes on mobile.** Rejected: mobile users still need semantic, side-by-side, and raw review modes.18+- **Keep the desktop two-column grid and rely on pinch zoom.** Rejected: it makes routine review painful and creates page-level horizontal overflow.@@ -0,0 +1,52 @@
1+# Mobile-Friendly Spec Browser Layout Delta2+3+## ADDED Requirements4+5+### Requirement: Mobile-friendly spec browser layout6+The dashboard spec browser SHALL remain usable on narrow mobile screens without page-level horizontal overflow.7+8+#### Scenario: Spec browser collapses to one column9+- **GIVEN** the dashboard is viewed on a narrow mobile viewport10+- **WHEN** the user opens the spec browser11+- **THEN** the file list and selected spec detail are arranged in a single-column layout instead of a fixed desktop two-column grid12+13+#### Scenario: Spec list remains navigable14+- **GIVEN** the dashboard is viewed on a narrow mobile viewport with multiple specs15+- **WHEN** the spec browser renders the file list16+- **THEN** the file list is horizontally scrollable within its own region and does not widen the whole page17+18+#### Scenario: Long spec text wraps safely19+- **GIVEN** a spec path, requirement name, scenario name, step text, or card title is longer than the available mobile width20+- **WHEN** the dashboard renders it21+- **THEN** the text wraps or truncates within its container without forcing horizontal page overflow22+23+### Requirement: Mobile-friendly spec diff layout24+The dashboard spec diff views SHALL preserve all review modes on narrow mobile screens while using readable stacked layouts where needed.25+26+#### Scenario: Side-by-side diff stacks on mobile27+- **GIVEN** the dashboard is viewed on a narrow mobile viewport28+- **WHEN** the user selects the side-by-side diff view29+- **THEN** the before and after diff panes stack vertically instead of requiring two columns across the viewport30+31+#### Scenario: Semantic scenario changes stack on mobile32+- **GIVEN** a semantic diff contains before and after scenario content33+- **WHEN** the dashboard renders it on a narrow mobile viewport34+- **THEN** the before and after scenario blocks stack vertically with readable line lengths35+36+#### Scenario: Diff mode controls remain reachable37+- **GIVEN** the dashboard is viewed on a narrow mobile viewport38+- **WHEN** the user opens dirty or refs mode in the spec browser39+- **THEN** semantic, side-by-side, and raw diff controls remain visible or horizontally scrollable instead of being hidden40+41+### Requirement: Mobile-friendly dashboard modal framing42+Dashboard modal and page framing SHALL adapt to narrow screens so spec content remains readable and close controls remain reachable.43+44+#### Scenario: Mobile modal uses reduced padding45+- **GIVEN** the dashboard opens a modal on a narrow mobile viewport46+- **WHEN** the modal renders47+- **THEN** the overlay and modal body use reduced padding and a viewport-bounded body height48+49+#### Scenario: Mobile page avoids horizontal overflow50+- **GIVEN** the dashboard is viewed on a narrow mobile viewport51+- **WHEN** the page renders board, toolbar, or spec browser controls52+- **THEN** the page prevents horizontal overflow while allowing bounded control groups to wrap or scroll@@ -0,0 +1,9 @@
1+## Tasks2+3+- [x] Add responsive CSS breakpoint for narrow dashboard screens4+- [x] Collapse spec browser grid to a single-column mobile layout5+- [x] Make spec list horizontally scrollable on mobile6+- [x] Stack diff columns and scenario before/after blocks on mobile7+- [x] Wrap long spec paths, requirement names, scenario names, step text, and card titles8+- [x] Reduce mobile modal/page padding and prevent page-level horizontal overflow9+- [x] Add OpenSpec coverage for mobile-friendly spec layout@@ -1,57 +1,44 @@
1-# Semantic Diff in Spec Browser Specification1+# Semantic Diff in Spec Browser Delta22 3-## Purpose4-5-Make spec diffing consistent between the change detail view and the spec browser by rendering the existing semantic requirement-level delta in both surfaces.6-7-## Requirements3+## ADDED Requirements84 95 ### Requirement: Semantic diff in spec browser payload10-11-The spec browser backend (`_spec_browser()` in `dashboard/plugin_api.py`) must include the full `semantic_diff` for each changed file, computed via the existing `_compute_semantic_diff()` helper.6+The spec browser backend SHALL include the full semantic requirement/scenario delta for changed spec files in dirty and ref comparison modes.127 138 #### Scenario: Dirty mode with changed specs14-15-- **GIVEN** a source with specs that differ between HEAD and the worktree9+- **GIVEN** a source with specs that differ between `HEAD` and the worktree1610 - **WHEN** the spec browser is loaded in dirty mode17-- **THEN** each changed file's payload includes a `semantic_diff` field with the structured requirement/scenario delta18-19-#### Scenario: Refs mode with changed specs11+- **THEN** each changed file payload includes a `semantic_diff` field with the structured requirement/scenario delta2012 13+#### Scenario: Ref comparison with changed specs2114 - **GIVEN** a source with specs that differ between two git refs2215 - **WHEN** the spec browser is loaded in refs mode with before and after refs23-- **THEN** each changed file's payload includes a `semantic_diff` field24-25-#### Scenario: Unchanged files excluded16+- **THEN** each changed file payload includes a `semantic_diff` field2617 27-- **GIVEN** a source with specs that are identical between the compared refs18+#### Scenario: Unchanged files omitted from semantic payload19+- **GIVEN** a source with specs that are identical between the compared versions2820 - **WHEN** the spec browser payload is computed29-- **THEN** unchanged files do not include a `semantic_diff` field (matching the existing `semantic_summary` gating)21+- **THEN** unchanged files do not include semantic diff data3022 31-### Requirement: View-mode toggle in spec browser frontend32-33-The spec browser frontend (`SpecsView` in `dashboard/dist/index.js`) must provide a view-mode toggle for dirty and refs modes, allowing the user to switch between semantic, side-by-side, and raw diff views.23+### Requirement: Diff view-mode toggle in spec browser24+The spec browser frontend SHALL provide a view-mode toggle for dirty and refs modes so maintainers can switch between semantic, side-by-side, and raw diff views.3425 3526 #### Scenario: Default to semantic view36-37-- **GIVEN** the spec browser is in dirty or refs mode with changed files38-- **WHEN** a changed file is selected39-- **THEN** the semantic delta view (`SpecDeltaView`) is shown by default27+- **GIVEN** the spec browser is in dirty or refs mode with a changed file selected28+- **WHEN** the detail pane renders29+- **THEN** the semantic delta view is shown by default4030 4131 #### Scenario: Switch to side-by-side42-4332 - **GIVEN** the spec browser is showing a semantic delta for a changed file44-- **WHEN** the user selects "Side-by-side" from the view-mode toggle45-- **THEN** the before and after spec content is rendered side-by-side using `SpecContentView`33+- **WHEN** the user selects the side-by-side mode34+- **THEN** the before and after spec content are rendered side by side4635 4736 #### Scenario: Switch to raw diff48-4937 - **GIVEN** the spec browser is showing a semantic delta for a changed file50-- **WHEN** the user selects "Raw" from the view-mode toggle51-- **THEN** the unified line diff is shown in a `<pre>` block38+- **WHEN** the user selects the raw mode39+- **THEN** the unified line diff is shown in a preformatted block5240 5341 #### Scenario: Current mode unaffected54-55-- **GIVEN** the spec browser is in current mode (no comparison)42+- **GIVEN** the spec browser is in current mode5643 - **WHEN** a file is selected57-- **THEN** the spec content is shown via `SpecContentView` with no view-mode toggle44+- **THEN** the spec content is shown without a diff view-mode toggle