feat(bearings): color-code board statuses and add keep/now/remove triage choices - #49
Closed
doitdigital0495 wants to merge 3 commits into
Closed
doitdigital0495 wants to merge 3 commits into
doitdigital0495 wants to merge 3 commits into
Conversation
…oices Status badges now read at a glance: request, project and person statuses map from their wording to danger/warn/online/info/done/neutral tones, unknown wording stays neutral, and the words always stay visible so color is a second signal, never the only one. Every requests row, optional knowledge entry, project and person whose routing id can carry a keyed answer gets one three-radio group (leave on backlog / do now / remove completely). Each section's send bar queues exactly one fm-bearings-answer.v1 choice annotation per marked row over the board's existing single answer path, keyed triage.<request|knowledge|project|crew>.<routing id>; rows whose ids cannot route render without choices. The keyed-answer intake keeps skipping non-task keys, so firstmate applies the choices from the captured result read. The payload contract gains only optional fields: knowledge[] entries and optional project ids, both slug-gated so full triage keys stay within the 128-character keyed-answer limit. The script header documents how firstmate reads a triage answer; SKILL.md points composers at the new optional fields. Verified: 19 board build tests, 24 render tests, full procevent and captain-hold suites, shellcheck/actionlint, and an in-browser pass at 390px and desktop width (distinct tone colors, no horizontal overflow, queue path exercised in the real DOM).
Owner
Author
|
Closed unmerged: the bearings board upgrade is being removed (see the revert PR). |
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
2 participants
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.
Intent
The bearings Lavish board needs to read at a glance and let the captain triage the whole board in one sitting: statuses must be color-coded so waiting-on-you, working, waiting, completed and unconfirmed look different at a glance on desktop and at 390px (wording stays visible, color is a second signal); every request row, an optional knowledge section, and every Projects and People item must carry a three-choice keep-on-backlog / do-now / remove-completely selection that flows through the board's existing Lavish answer path as one versioned choice per marked row; the payload contract extends with optional fields only, the board script header documents exactly how firstmate reads such an answer, and the result ships as one PR with sample-build plus 390px and desktop screenshot proof.
What Changed
backlog), do now (now) or remove completely (remove). This covers request rows, the new optionalknowledgesection, projects (through a new optionalid) and crew. Each section's send bar queues every marked row as its ownfm-bearings-answer.v1choice, keyedtriage.<request|knowledge|project|crew>.<id>, through the existingwindow.lavish.queuePromptanswer path. A choice that is changed after queueing can be sent again.bin/fm-bearings-board.shvalidates the optionalknowledge[]entries and the optional projectid: unique slug ids whose full triage key stays within 128 characters. Its header now documents how firstmate reads a triage answer and applies it. The bearings SKILL.md describes the new optional fields. The render harness and the board tests cover the status colors, the triage choices and the new validation.🤖 Generated with Claude Code
Risk Assessment
✅ Low: The change adds optional payload fields with matching validation and only touches UI rendering. It reuses the existing Lavish answer path under a namespaced key that cannot resolve a captain-held task. The one real defect, a choice changed after sending is not re-sent, is UX-level and easy to fix.
Testing
Built the sample payload with the real build script. It produced a live, armed Lavish session, which I drove in headless Chrome. Marking a request Do now and sending it queued
now. Switching the same row to Remove re-enabled the send bar, and the second send replaced the queued prompt withremove. The captured result that firstmate reads lists exactly four choices (request remove, knowledge remove, project backlog, crew remove), and the stalenowis not among them. Screenshots at 390px show request rows stacked, with badges such as UNCONFIRMED and labels such as 'Remove completely' each on one line. At 1440px the three-column table is kept, with distinct status colors. The targeted render and build test scripts both passed. Setup note: the throwaway FM_HOME needed umask 077 because the process-event state root must be a private directory.Evidence: Sample build transcript (round 2)
Source: Sample build transcript (round 2)
Evidence: Queue after changing a sent choice (now -> remove)
Source: Queue after changing a sent choice (now -> remove)
Evidence: Firstmate read of captured board result
Source: Firstmate read of captured board result
Pipeline
Updates from git push no-mistakes
✅ **intent** - passed
✅ No issues found.
✅ **Rebase** - passed
✅ No issues found.
.agents/skills/bearings/assets/board-template.html:667- After a section's choices are sent, each group getsis-queued, but its radios stay enabled, andpendingGroups()filters out queued groups for good. Repro: the captain marks a request 'Do now' and clicks Send, which queuesnow. They then switch the same row to 'Remove completely'. The row now shows Remove with a 'sent' chip, the count reads 'no choice marked', and the send button is disabled, so the answer firstmate reads is stillnow. The page shows a different choice from the one that was sent, and nothing signals the mismatch. The Captain's Call option cards (line 912-928) allow re-answering. Fix: onchange, removeis-queuedfrom that group (and from the bar) so it can be re-sent under the same queueKey. The alternative is to disable a group's inputs once it is queued. The same logic serves all three bars (requests, knowledge, projects/people) through armTriageBar at lines 1112-1116.bin/fm-bearings-board.sh:217- Knowledge and project ids are validated against the triage key shape (triage_id), but request ids (line 217) and crew ids (line 233) are onlynonempty_string. A request whose id falls outside [A-Za-z0-9._-] or is longer than 113 characters (triage.request.+ id > 128, e.g. a long legacy<origin>-decision-<key>id) builds fine but renders with no keep/now/remove group (templatetriageKey, line 154). The header documents this as intended ('a row whose id cannot route simply renders without choices'), so it is not a defect. It is still a quiet gap against the intent's 'every request row'. In practice task ids are short slugs.🔧 Fix applied.
1 info still open:
bin/fm-bearings-board.sh:217- Knowledge and project ids are validated against the triage key shape (triage_id), but request ids (line 217) and crew ids (line 233) are onlynonempty_string. A request whose id falls outside [A-Za-z0-9._-] or is longer than 113 characters (triage.request.+ id > 128, e.g. a long legacy<origin>-decision-<key>id) builds fine but renders with no keep/now/remove group (templatetriageKey, line 154). The header documents this as intended ('a row whose id cannot route simply renders without choices'), so it is not a defect. It is still a quiet gap against the intent's 'every request row'. In practice task ids are short slugs.🔧 **Test** - 1 issue found → auto-fixed ✅
.agents/skills/bearings/assets/board-template.html- At 390px the requests table's narrow columns break labels in the middle of a word: the 'UNCONFIRMED' status badge wraps as 'UNCONFIRME / D' and 'Remove completely' wraps as 'Remove completel / y' on every request row (see mobile-390-full.png). The wording stays visible, but the break is visible and looks off on the phone layout the intent calls for. A likely fix is to stop forced word breaking in those cells (e.g. overflow-wrap: normal / white-space: nowrap on badges and choice labels) or to stack the choice column below the row at narrow widths.fm-procevent-lavish.sh readlists each '<title> -> <label>' andanswersemits one keyed triage.* row per marked rowfm-captain-hold.sh answers) skips triage.* keys as the header documentsbin/fm-bearings-board.sh build sample-payload.jsonin a lab FM_HOME (/tmp/fm-lab-triage.*): real lavish-axi session opened, bound, armed, listening liveChrome (isolated chrome-devtools-axi session fm-lab-triage) on the Lavish session: clicked choices in the requests, knowledge and projects/people sections and clicked each section's Send my choicesRe-send scenario: marked 'Do now' on a request, sent it, switched the row to 'Remove completely', checked that the bar re-enabled, and sent againClicked Lavish 'Send to Agent'; the armed listener captured the result into the lab procevent-inboxbin/fm-procevent-lavish.sh read <result>andbin/fm-procevent-lavish.sh answers <result>on the captured resultFull-page screenshots of the artifact at 390x3728 and 1440x2279; scrollWidth 390 at 390px (no horizontal overflow); read the computed badge colors per statusValidator rejections: knowledge id with spaces, duplicate knowledge id, project id 'x/y', knowledge id over the 128-char key limitPayload without knowledge[] and without project ids passes validation (stubbed lavish-axi)Teardown:fm-procevent-lavish.sh retire,lavish-axi end, lab dir removed, Chrome session stopped🔧 Fix applied.
✅ Re-checked - no issues remain.
FM_HOME=<tmp> bin/fm-bearings-board.sh build sample-payload.json(live Lavish session, bound+armed+listening)chrome-devtools-axi (isolated session nm-test-r2): mark 'Approve DNS cutover' Do now -> Send -> switch to Remove completely -> verify bar re-enabled ('1 choice marked to send') -> Send -> queue holds single remove promptchrome-devtools-axi: mark knowledge 'Old staging host' remove, project 'Invoices' backlog, crew 'Sam' remove, send each bar, then 'Send to Agent'bin/fm-procevent-lavish.sh read <captured .result>: firstmate's read of the captured answerfile:// render of built board at 390x3760 full page + 390 requests viewport + 1440 requests viewport screenshots; JS check for single-word labels wrapping (none)bash tests/fm-bearings-board-render.test.shbash tests/fm-bearings-board.test.sh✅ **Document** - passed
✅ No issues found.
✅ **Lint** - passed
✅ No issues found.
✅ **Push** - passed
✅ No issues found.