mirror of
https://github.com/ksyasuda/SubMiner.git
synced 2026-03-20 03:16:46 -07:00
Automate AUR publish in tagged release workflow (#22)
This commit is contained in:
GitHub
@@ -20,3 +20,5 @@ Notes:
|
||||
|
||||
- `changelog:check` now rejects tag/package version mismatches.
|
||||
- Do not tag while `changes/*.md` fragments still exist.
|
||||
- Tagged release workflow now also attempts to update `subminer-bin` on the AUR after GitHub Release publication.
|
||||
- Required GitHub Actions secret: `AUR_SSH_PRIVATE_KEY`. Add the matching public key to your AUR account before relying on the automation.
|
||||
|
||||
@@ -1,105 +0,0 @@
|
||||
# SubMiner Change Verification Skill Design
|
||||
|
||||
**Date:** 2026-03-10
|
||||
**Status:** Approved
|
||||
|
||||
## Goal
|
||||
|
||||
Create a SubMiner-specific skill that agents can use to verify code changes with automated checks. The skill must support both targeted regression testing during debugging and pre-handoff verification before final response.
|
||||
|
||||
## Skill Contract
|
||||
|
||||
- **Name:** `subminer-change-verification`
|
||||
- **Trigger:** Use when working in the SubMiner repo and you need to verify code changes actually work, especially for launcher, mpv, plugin, overlay, runtime, Electron, or env-sensitive behavior.
|
||||
- **Default posture:** cheap-first; prefer repo-native tests and narrow lanes before broader or GUI-dependent verification.
|
||||
- **Outputs:**
|
||||
- verification summary
|
||||
- exact commands run
|
||||
- artifact paths for logs, captured summaries, and preserved temp state on failures
|
||||
- skipped lanes and blockers
|
||||
- **Non-goals:**
|
||||
- replacing the repo's native tests
|
||||
- launching real GUI apps for every change
|
||||
- default visual regression or pixel-diff workflows
|
||||
|
||||
## Lane Selection
|
||||
|
||||
The skill chooses lanes from the diff or explicit file list.
|
||||
|
||||
- **`docs`**
|
||||
- For `docs-site/`, `docs/`, and similar documentation-only changes.
|
||||
- Prefer `bun run docs:test` and `bun run docs:build`.
|
||||
- **`config`**
|
||||
- For `src/config/`, config example generation/verification paths, and config-template-sensitive changes.
|
||||
- Prefer `bun run test:config`.
|
||||
- **`core`**
|
||||
- For general source-level changes where type safety and the fast maintained lane are the best cheap signal.
|
||||
- Prefer `bun run typecheck` and `bun run test:fast`.
|
||||
- **`launcher-plugin`**
|
||||
- For `launcher/`, `plugin/subminer/`, plugin gating scripts, and wrapper/mpv routing work.
|
||||
- Prefer `bun run test:launcher:smoke:src` and `bun run test:plugin:src`.
|
||||
- **`runtime-compat`**
|
||||
- For runtime/composition/bundled behavior where dist-sensitive validation matters.
|
||||
- Prefer `bun run build`, `bun run test:runtime:compat`, and `bun run test:smoke:dist`.
|
||||
- **`real-gui`**
|
||||
- Reserved for cases where actual Electron/mpv/window behavior must be validated.
|
||||
- Not part of the default lane set; the classifier marks these changes as candidates so the agent can escalate deliberately.
|
||||
|
||||
## Escalation Rules
|
||||
|
||||
1. Start with the narrowest lane that credibly exercises the changed behavior.
|
||||
2. If a narrow lane fails in a way that suggests broader fallout, expand once.
|
||||
3. If a change touches launcher/mpv/plugin/runtime/overlay/window tracking paths, include the relevant specialized lanes before falling back to broad suites.
|
||||
4. Treat real GUI/mpv verification as opt-in escalation:
|
||||
- use only when cheaper evidence is insufficient
|
||||
- allow for platform/display/permission blockers
|
||||
- report skipped/blocker states explicitly
|
||||
|
||||
## Helper Script Design
|
||||
|
||||
The skill uses two small shell helpers:
|
||||
|
||||
- **`scripts/classify_subminer_diff.sh`**
|
||||
- Accepts explicit paths or discovers local changes from git.
|
||||
- Emits lane suggestions and flags in a simple line-oriented format.
|
||||
- Marks real GUI-sensitive paths as `flag:real-gui-candidate` instead of forcing GUI execution.
|
||||
- **`scripts/verify_subminer_change.sh`**
|
||||
- Creates an artifact directory under `.tmp/skill-verification/<timestamp>/`.
|
||||
- Selects lanes from the classifier unless lanes are supplied explicitly.
|
||||
- Runs repo-native commands in a stable order and captures stdout/stderr per step.
|
||||
- Writes a compact `summary.json` and a human-readable `summary.txt`.
|
||||
- Skips real GUI verification unless explicitly enabled.
|
||||
|
||||
## Artifact Contract
|
||||
|
||||
Each invocation should create:
|
||||
|
||||
- `summary.json`
|
||||
- `summary.txt`
|
||||
- `classification.txt`
|
||||
- `env.txt`
|
||||
- `lanes.txt`
|
||||
- `steps.tsv`
|
||||
- `steps/<step>.stdout.log`
|
||||
- `steps/<step>.stderr.log`
|
||||
|
||||
Failures should preserve the artifact directory and identify the exact failing command and log paths.
|
||||
|
||||
## Agent Workflow
|
||||
|
||||
1. Inspect changed files or requested area.
|
||||
2. Classify the change into verification lanes.
|
||||
3. Run the cheapest sufficient lane set.
|
||||
4. Escalate only if evidence is insufficient.
|
||||
5. Escalate to real GUI/mpv only for actual Electron/mpv/window behavior claims.
|
||||
6. Return a short report with:
|
||||
- pass/fail/skipped per lane
|
||||
- exact commands run
|
||||
- artifact paths
|
||||
- blockers/gaps
|
||||
|
||||
## Initial Implementation Scope
|
||||
|
||||
- Ship the skill entrypoint plus the classifier/verifier helpers.
|
||||
- Make real GUI verification an explicit future hook rather than a default workflow.
|
||||
- Verify the new skill locally with representative classifier output and artifact generation.
|
||||
@@ -1,111 +0,0 @@
|
||||
# SubMiner Scrum Master Skill Design
|
||||
|
||||
**Date:** 2026-03-10
|
||||
**Status:** Approved
|
||||
|
||||
## Goal
|
||||
|
||||
Create a repo-local skill that can take incoming requests, bugs, or issues in the SubMiner repo, decide whether backlog tracking is warranted, create or update backlog work when appropriate, plan the implementation, dispatch one or more subagents, and ensure verification happens before handoff.
|
||||
|
||||
## Skill Contract
|
||||
|
||||
- **Name:** `subminer-scrum-master`
|
||||
- **Location:** `.agents/skills/subminer-scrum-master/`
|
||||
- **Use when:** the user gives a feature request, bug report, issue, refactor, or implementation ask in the SubMiner repo and the agent should own intake, planning, backlog hygiene, dispatch, and completion flow.
|
||||
- **Responsibilities:**
|
||||
- assess whether backlog tracking is warranted
|
||||
- if needed, search/update/create proper backlog structure
|
||||
- write a plan before dispatching coding work
|
||||
- choose sequential vs parallel execution
|
||||
- assign explicit ownership to workers
|
||||
- require verification before final handoff
|
||||
- **Limits:**
|
||||
- not the default code implementer unless delegation would be wasteful
|
||||
- no overlapping parallel write scopes
|
||||
- no skipping planning before dispatch
|
||||
- no skipping verification
|
||||
- must pause for ambiguous, risky, or external side-effect work
|
||||
|
||||
## Backlog Decision Rules
|
||||
|
||||
Backlog use is conditional, not mandatory.
|
||||
|
||||
- **Skip backlog when:**
|
||||
- question only
|
||||
- obvious mechanical edit
|
||||
- tiny isolated change with no real planning
|
||||
- **Use backlog when:**
|
||||
- implementation requires planning
|
||||
- scope/approach needs decisions
|
||||
- multiple phases or subsystems
|
||||
- likely subagent dispatch
|
||||
- work should remain traceable
|
||||
|
||||
When backlog is used:
|
||||
- search first
|
||||
- update existing matching work when appropriate
|
||||
- otherwise create standalone task or parent task
|
||||
- use parent + subtasks for multi-part work
|
||||
- record the implementation plan before coding starts
|
||||
|
||||
## Orchestration Policy
|
||||
|
||||
The skill orchestrates; workers implement.
|
||||
|
||||
- **No dispatch** for trivial/mechanical work
|
||||
- **Single worker** for focused single-scope work
|
||||
- **Parallel workers** only for clearly disjoint scopes
|
||||
- **Sequential flow** for shared files, runtime coupling, or unclear boundaries
|
||||
|
||||
Every worker should receive:
|
||||
- owned files/modules
|
||||
- explicit reminder not to revert unrelated edits
|
||||
- requirement to report changed files, tests run, and blockers
|
||||
|
||||
## Verification Policy
|
||||
|
||||
Every nontrivial code task gets verification.
|
||||
|
||||
- prefer `subminer-change-verification`
|
||||
- use cheap-first lanes
|
||||
- escalate only when needed
|
||||
- accept worker-run verification only if it is clearly relevant and sufficient
|
||||
- run a consolidating final verification pass when the scrum master needs stronger evidence
|
||||
|
||||
## Representative Flows
|
||||
|
||||
### Trivial fix, no backlog
|
||||
|
||||
1. assess request as mechanical or narrowly reversible
|
||||
2. skip backlog
|
||||
3. keep a short internal plan
|
||||
4. implement directly or use one worker if helpful
|
||||
5. run targeted verification
|
||||
6. report concise summary
|
||||
|
||||
### Single-task implementation
|
||||
|
||||
1. search backlog
|
||||
2. create/update one task
|
||||
3. record plan
|
||||
4. dispatch one worker
|
||||
5. integrate result
|
||||
6. run verification
|
||||
7. update task and report outcome
|
||||
|
||||
### Multi-part feature
|
||||
|
||||
1. search backlog
|
||||
2. create/update parent task
|
||||
3. create subtasks for distinct deliverables/phases
|
||||
4. record sequencing in the plan
|
||||
5. dispatch workers only where write scopes do not overlap
|
||||
6. integrate
|
||||
7. run consolidated verification
|
||||
8. update task state and report outcome
|
||||
|
||||
## V1 Scope
|
||||
|
||||
- instruction-heavy `SKILL.md`
|
||||
- no helper scripts unless orchestration becomes too repetitive
|
||||
- strong coordination with existing Backlog workflow and `subminer-change-verification`
|
||||
@@ -1,110 +0,0 @@
|
||||
# Overlay Controller Support Design
|
||||
|
||||
**Date:** 2026-03-11
|
||||
**Backlog:** `TASK-159`
|
||||
|
||||
## Goal
|
||||
|
||||
Add controller support to the visible overlay through the Chrome Gamepad API without replacing the existing keyboard-only workflow. Controller input should only supplement keyboard-only mode, preserve existing behavior, and expose controller selection plus raw-input debugging in overlay-local modals.
|
||||
|
||||
## Scope
|
||||
|
||||
- Poll connected gamepads from the visible overlay renderer.
|
||||
- Default to the first connected controller unless config specifies a preferred controller.
|
||||
- Add logical controller bindings and tuning knobs to config.
|
||||
- Add `Alt+C` controller selection modal.
|
||||
- Add `Alt+Shift+C` controller debug modal.
|
||||
- Map controller actions onto existing keyboard-only/Yomitan behaviors.
|
||||
- Fix stale selected-token highlight cleanup when keyboard-only mode turns off or popup closes.
|
||||
|
||||
Out of scope for this pass:
|
||||
|
||||
- Raw arbitrary axis/button index remapping in config.
|
||||
- Controller support outside the visible overlay renderer.
|
||||
- Haptics or vibration.
|
||||
|
||||
## Architecture
|
||||
|
||||
Use a renderer-local controller runtime. The overlay already owns keyboard-only token selection, Yomitan popup integration, and modal UX, and the Gamepad API is browser-native. A renderer module can poll `navigator.getGamepads()` on animation frames, normalize sticks/buttons into logical actions, and call the same helpers used by keyboard-only mode.
|
||||
|
||||
Avoid synthetic keyboard events as the primary implementation. Analog sticks need deadzones, continuous smooth scrolling, and per-action repeat behavior that do not fit cleanly into key event emulation. Direct logical actions keep tests clear and make the debug modal show the exact values the runtime uses.
|
||||
|
||||
## Behavior
|
||||
|
||||
Controller actions are active only while keyboard-only mode is enabled, except the controller action that toggles keyboard-only mode can always fire so the user can enter the mode from the controller.
|
||||
|
||||
Default logical mappings:
|
||||
|
||||
- left stick vertical: smooth Yomitan popup/window scroll when popup is open
|
||||
- left stick horizontal: move token selection left/right
|
||||
- right stick vertical: smooth Yomitan popup/window scroll
|
||||
- right stick horizontal: jump horizontally inside Yomitan popup/window
|
||||
- `A`: toggle lookup
|
||||
- `B`: close lookup
|
||||
- `Y`: toggle keyboard-only mode
|
||||
- `X`: mine card
|
||||
- `L1` / `R1`: previous / next Yomitan audio
|
||||
- `R2`: activate current Yomitan audio button
|
||||
- `L2`: toggle mpv play/pause
|
||||
|
||||
Selection-highlight cleanup:
|
||||
|
||||
- disabling keyboard-only mode clears the selected token class immediately
|
||||
- closing the Yomitan popup also clears the selected token class if keyboard-only mode is no longer active
|
||||
- helper ownership should live in the shared keyboard-only selection sync path so keyboard and controller exits stay consistent
|
||||
|
||||
## Config
|
||||
|
||||
Add a top-level `controller` block in resolved config with:
|
||||
|
||||
- `enabled`
|
||||
- `preferredGamepadId`
|
||||
- `preferredGamepadLabel`
|
||||
- `smoothScroll`
|
||||
- `scrollPixelsPerSecond`
|
||||
- `horizontalJumpPixels`
|
||||
- `stickDeadzone`
|
||||
- `triggerDeadzone`
|
||||
- `repeatDelayMs`
|
||||
- `repeatIntervalMs`
|
||||
- `bindings` logical fields for the named actions/sticks
|
||||
|
||||
Persist the preferred controller by stable browser-exposed `id` when possible, with label stored as a diagnostic/display fallback.
|
||||
|
||||
## UI
|
||||
|
||||
Controller selection modal:
|
||||
|
||||
- overlay-hosted modal in the visible renderer
|
||||
- lists currently connected controllers
|
||||
- highlights current active choice
|
||||
- selecting one persists config and makes it the active controller immediately if connected
|
||||
|
||||
Controller debug modal:
|
||||
|
||||
- overlay-hosted modal
|
||||
- shows selected controller and all connected controllers
|
||||
- live raw axis array values
|
||||
- live raw button values, pressed flags, and touched flags if available
|
||||
|
||||
## Testing
|
||||
|
||||
Test first:
|
||||
|
||||
- controller gating outside keyboard-only mode
|
||||
- logical mapping to existing helpers
|
||||
- continuous stick scroll and repeat behavior
|
||||
- modal open shortcuts
|
||||
- preferred-controller selection persistence
|
||||
- highlight cleanup on keyboard-only disable and popup close
|
||||
- config defaults/parse/template generation coverage
|
||||
|
||||
## Risks
|
||||
|
||||
- Browser gamepad identity strings can differ across OS/browser/runtime versions.
|
||||
Mitigation: match by exact preferred id first; fall back to first connected controller.
|
||||
- Continuous stick input can spam actions.
|
||||
Mitigation: deadzones plus repeat throttling and frame-time-based smooth scroll.
|
||||
- Popup DOM/audio controls may vary.
|
||||
Mitigation: target stable Yomitan popup/document selectors and cover with focused renderer tests.
|
||||
|
||||
@@ -1,245 +0,0 @@
|
||||
# Overlay Controller Support Implementation Plan
|
||||
|
||||
> **For Claude:** REQUIRED SUB-SKILL: Use superpowers:executing-plans to implement this plan task-by-task.
|
||||
|
||||
**Goal:** Add Chrome Gamepad API controller support to the visible overlay as a supplement to keyboard-only mode, including controller selection/debug modals, config-backed logical bindings, and selected-token highlight cleanup.
|
||||
|
||||
**Architecture:** Keep controller support in the visible overlay renderer. Poll and normalize gamepad state in a dedicated runtime, route logical actions into the existing keyboard-only/Yomitan helpers, and persist preferred-controller config through the existing config pipeline and preload bridge.
|
||||
|
||||
**Tech Stack:** TypeScript, Bun tests, Electron preload IPC, renderer DOM modals, Chrome Gamepad API
|
||||
|
||||
---
|
||||
|
||||
### Task 1: Track work and lock the design
|
||||
|
||||
**Files:**
|
||||
- Create: `backlog/tasks/task-159 - Add-overlay-controller-support-for-keyboard-only-mode.md`
|
||||
- Create: `docs/plans/2026-03-11-overlay-controller-support-design.md`
|
||||
- Create: `docs/plans/2026-03-11-overlay-controller-support.md`
|
||||
|
||||
**Step 1: Record the approved scope**
|
||||
|
||||
Capture controller-only-in-keyboard-mode behavior, the modal shortcuts, config scope, and the stale selection-highlight cleanup requirement.
|
||||
|
||||
**Step 2: Verify the written scope matches the approved design**
|
||||
|
||||
Run: `sed -n '1,220p' backlog/tasks/task-159\\ -\\ Add-overlay-controller-support-for-keyboard-only-mode.md && sed -n '1,240p' docs/plans/2026-03-11-overlay-controller-support-design.md`
|
||||
|
||||
Expected: task and design doc both mention controller selection/debug modals and highlight cleanup.
|
||||
|
||||
### Task 2: Add failing config tests and defaults
|
||||
|
||||
**Files:**
|
||||
- Modify: `src/config/config.test.ts`
|
||||
- Modify: `src/config/definitions/defaults-core.ts`
|
||||
- Modify: `src/config/definitions/options-core.ts`
|
||||
- Modify: `src/config/definitions/template-sections.ts`
|
||||
- Modify: `src/types.ts`
|
||||
- Modify: `config.example.jsonc`
|
||||
|
||||
**Step 1: Write the failing test**
|
||||
|
||||
Add coverage asserting a new `controller` config block resolves with the expected defaults and accepts logical-field overrides.
|
||||
|
||||
**Step 2: Run test to verify it fails**
|
||||
|
||||
Run: `bun test src/config/config.test.ts`
|
||||
|
||||
Expected: FAIL because `controller` config is not defined yet.
|
||||
|
||||
**Step 3: Write minimal implementation**
|
||||
|
||||
Add the controller config types/defaults/registry/template wiring and regenerate the example config if needed.
|
||||
|
||||
**Step 4: Run test to verify it passes**
|
||||
|
||||
Run: `bun test src/config/config.test.ts`
|
||||
|
||||
Expected: PASS
|
||||
|
||||
### Task 3: Add failing keyboard-selection cleanup tests
|
||||
|
||||
**Files:**
|
||||
- Modify: `src/renderer/handlers/keyboard.test.ts`
|
||||
- Modify: `src/renderer/handlers/keyboard.ts`
|
||||
- Modify: `src/renderer/state.ts`
|
||||
|
||||
**Step 1: Write the failing tests**
|
||||
|
||||
Add tests for:
|
||||
|
||||
- turning keyboard-only mode off clears `.keyboard-selected`
|
||||
- closing the popup clears stale selection highlight when keyboard-only mode is off
|
||||
|
||||
**Step 2: Run test to verify it fails**
|
||||
|
||||
Run: `bun test src/renderer/handlers/keyboard.test.ts`
|
||||
|
||||
Expected: FAIL because selection cleanup is incomplete today.
|
||||
|
||||
**Step 3: Write minimal implementation**
|
||||
|
||||
Centralize selection clearing in the keyboard-only sync helpers and popup-close flow.
|
||||
|
||||
**Step 4: Run test to verify it passes**
|
||||
|
||||
Run: `bun test src/renderer/handlers/keyboard.test.ts`
|
||||
|
||||
Expected: PASS
|
||||
|
||||
### Task 4: Add failing controller runtime tests
|
||||
|
||||
**Files:**
|
||||
- Create: `src/renderer/handlers/gamepad-controller.test.ts`
|
||||
- Create: `src/renderer/handlers/gamepad-controller.ts`
|
||||
- Modify: `src/renderer/context.ts`
|
||||
- Modify: `src/renderer/state.ts`
|
||||
- Modify: `src/renderer/renderer.ts`
|
||||
|
||||
**Step 1: Write the failing tests**
|
||||
|
||||
Cover:
|
||||
|
||||
- first connected controller is selected by default
|
||||
- preferred controller wins when connected
|
||||
- controller actions are ignored unless keyboard-only mode is enabled, except keyboard-only toggle
|
||||
- stick/button mappings invoke the expected logical helpers
|
||||
- smooth scroll and repeat throttling behavior
|
||||
|
||||
**Step 2: Run test to verify it fails**
|
||||
|
||||
Run: `bun test src/renderer/handlers/gamepad-controller.test.ts`
|
||||
|
||||
Expected: FAIL because controller runtime does not exist.
|
||||
|
||||
**Step 3: Write minimal implementation**
|
||||
|
||||
Add a renderer-local polling runtime with deadzone handling, action edge detection, repeat timing, and helper callbacks into the keyboard/Yomitan flow.
|
||||
|
||||
**Step 4: Run test to verify it passes**
|
||||
|
||||
Run: `bun test src/renderer/handlers/gamepad-controller.test.ts`
|
||||
|
||||
Expected: PASS
|
||||
|
||||
### Task 5: Add failing controller modal tests
|
||||
|
||||
**Files:**
|
||||
- Modify: `src/renderer/index.html`
|
||||
- Modify: `src/renderer/style.css`
|
||||
- Create: `src/renderer/modals/controller-select.ts`
|
||||
- Create: `src/renderer/modals/controller-select.test.ts`
|
||||
- Create: `src/renderer/modals/controller-debug.ts`
|
||||
- Create: `src/renderer/modals/controller-debug.test.ts`
|
||||
- Modify: `src/renderer/renderer.ts`
|
||||
- Modify: `src/renderer/context.ts`
|
||||
- Modify: `src/renderer/state.ts`
|
||||
|
||||
**Step 1: Write the failing tests**
|
||||
|
||||
Add tests for:
|
||||
|
||||
- `Alt+C` opens controller selection modal
|
||||
- `Alt+Shift+C` opens controller debug modal
|
||||
- selection modal renders connected controllers and persists the chosen device
|
||||
- debug modal shows live axes/buttons state
|
||||
|
||||
**Step 2: Run test to verify it fails**
|
||||
|
||||
Run: `bun test src/renderer/modals/controller-select.test.ts src/renderer/modals/controller-debug.test.ts`
|
||||
|
||||
Expected: FAIL because modals and shortcuts do not exist.
|
||||
|
||||
**Step 3: Write minimal implementation**
|
||||
|
||||
Add modal DOM, renderer modules, modal state wiring, and controller runtime integration.
|
||||
|
||||
**Step 4: Run test to verify it passes**
|
||||
|
||||
Run: `bun test src/renderer/modals/controller-select.test.ts src/renderer/modals/controller-debug.test.ts`
|
||||
|
||||
Expected: PASS
|
||||
|
||||
### Task 6: Persist controller preference through preload/main wiring
|
||||
|
||||
**Files:**
|
||||
- Modify: `src/preload.ts`
|
||||
- Modify: `src/types.ts`
|
||||
- Modify: `src/shared/ipc/contracts.ts`
|
||||
- Modify: `src/core/services/ipc.ts`
|
||||
- Modify: `src/main.ts`
|
||||
- Modify: related main/runtime tests as needed
|
||||
|
||||
**Step 1: Write the failing test**
|
||||
|
||||
Add coverage for reading current controller config and saving preferred-controller changes from the renderer.
|
||||
|
||||
**Step 2: Run test to verify it fails**
|
||||
|
||||
Run: `bun test src/core/services/ipc.test.ts`
|
||||
|
||||
Expected: FAIL because no controller preference IPC exists yet.
|
||||
|
||||
**Step 3: Write minimal implementation**
|
||||
|
||||
Expose renderer-safe getters/setters for the controller config fields needed by the selection modal/runtime.
|
||||
|
||||
**Step 4: Run test to verify it passes**
|
||||
|
||||
Run: `bun test src/core/services/ipc.test.ts`
|
||||
|
||||
Expected: PASS
|
||||
|
||||
### Task 7: Update docs and config example
|
||||
|
||||
**Files:**
|
||||
- Modify: `config.example.jsonc`
|
||||
- Modify: `README.md`
|
||||
- Modify: relevant docs under `docs-site/` for shortcuts/usage/troubleshooting if touched by current docs structure
|
||||
|
||||
**Step 1: Write the failing doc/config check if needed**
|
||||
|
||||
If config example generation is covered by tests, add/refresh the failing assertion first.
|
||||
|
||||
**Step 2: Implement the docs**
|
||||
|
||||
Document controller behavior, modal shortcuts, config block, and the keyboard-only-only activation rule.
|
||||
|
||||
**Step 3: Run doc/config verification**
|
||||
|
||||
Run: `bun run test:config`
|
||||
|
||||
Expected: PASS
|
||||
|
||||
### Task 8: Run the handoff gate and update the backlog task
|
||||
|
||||
**Files:**
|
||||
- Modify: `backlog/tasks/task-159 - Add-overlay-controller-support-for-keyboard-only-mode.md`
|
||||
|
||||
**Step 1: Run targeted verification**
|
||||
|
||||
Run:
|
||||
|
||||
- `bun test src/config/config.test.ts`
|
||||
- `bun test src/renderer/handlers/keyboard.test.ts`
|
||||
- `bun test src/renderer/handlers/gamepad-controller.test.ts`
|
||||
- `bun test src/renderer/modals/controller-select.test.ts`
|
||||
- `bun test src/renderer/modals/controller-debug.test.ts`
|
||||
- `bun test src/core/services/ipc.test.ts`
|
||||
|
||||
Expected: PASS
|
||||
|
||||
**Step 2: Run broader gate**
|
||||
|
||||
Run:
|
||||
|
||||
- `bun run typecheck`
|
||||
- `bun run test:fast`
|
||||
- `bun run test:env`
|
||||
- `bun run build`
|
||||
|
||||
Expected: PASS, or document exact blockers/failures.
|
||||
|
||||
**Step 3: Update backlog notes**
|
||||
|
||||
Fill in implementation notes, verification commands, and final summary in `TASK-159`.
|
||||
Reference in New Issue
Block a user