main
2 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
| 755c976841 |
T7.2 - F6/D3: the form gets structure - a section rail, one section open
F6 as amended by D3 (Aug 18): one page, persistent side navigation, sections collapsible, only the current one open by default, plus Expand all. Tabs were rejected in D3 because they hide sections a first-time author does not know exist. What changed: - The jump-chip strip (#section-nav, span onclick) is gone. In its place a <nav> section rail of real <button> entries, aria-current on the current section, 44px tap targets, above the form at 390px and beside it at 1440px. - Every section heading is now a disclosure <button> with aria-expanded and aria-controls. One section open at rest; Expand all (aria-pressed) opens everything and is remembered per browser. - Sections are URL-addressable (?section=, T4.2 machinery) and a deep link to a collapsed section expands it. Positional-id fallback removed: a card without an id gets a console.error and no rail entry, never an invented sec-N id that would ride into shareable URLs and move between visits. - General Information (1,288px on its own) split into #general-card and #assign-card (Assignment & Schedule). The split is presentational: both cards are the ONE CR-006 section `general` (WP_SECTION_NODES lists both), so wp-sections.js and the SOP wizard are untouched. CR-001's adjacency (P6 activity beside due date) is preserved and asserted. - gotoSection() flushes autosave, which the deleted chips used to do. - secMakeToggle() preserves every element child of a heading - help tips go outside the button, everything else inside the label. The first version cleared textContent and destroyed #saved-count, which killed boot one line short of wpCreatorReady with the page still visibly rendered. - BL-013 folded in per the task: the T3.4 focus ring on the rebuilt form. frame_check reports outline solid 2px on creator inputs. Height, measured not asserted: 5,399px before; 1,995px at rest at 1440x900. DONE-WHEN NOT FULLY MET - stated per CLAUDE.md rather than marked complete: "no single view exceeds roughly two screen heights at rest" reads 2.22 screens (1995/900). The remaining gap is page chrome this wave reworks: .ctx-bar (67px, T7.4) and .release-banner (45px, T7.5). The criterion was already amended once (D3, "at rest") and is not being moved again to fit; tests/form_structure_check.py keeps the check red and it is re-measured at the end of wave 7. Every other done-when entry passes. Backlog: BL-001's cause corrected a third time - at rest the overflow is help.js's .help-tip::after tooltip (481 vs 390), the S8 component T9.5 rebuilds; the tables still overflow only when expanded. Deliberately not fixed here - a fix would be thrown away with the component at T9.5. Verification (each probe run alone): form_structure_check 50/51 (the height check above), sections_check 95/95, generalinfo_check 49/49, frame_check 39/39 regression pass. Items: F6, D3, BL-013, BL-001 (re-measured) Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
|||
| ce2d008897 |
T6.1/T6.2 - CR-001 and CR-003: the schedule driver and the urgency
Two fields and one board column mechanism, committed together because the second
is only there for the first: the board had NO sorting at all, CR-001 asks for a
sortable column, and CR-003 asks for another. Building the mechanism twice, or
building it once and pretending the second task got it free, are both worse than
saying so.
CR-001 - P6 activity ID and description
Every work package traces back to the schedule activity that drives it, so a
date on a package is anchored rather than floating. Placed beside the due
date, which is where the meeting put it and the reason it is there.
Free text. A validated lookup against an imported activity list is deferred
(BL-000a) partly because the Micron schedule is being reworked - importing it
now would import churn.
Both fields live inside General Information, so CR-006's toggle governs them
without any further wiring. The probe checks that by turning the section off
and reading the rendered document, rather than by asserting they are in the
right <div>.
CR-003 - Priority
Three levels, agreed live in the meeting, and no fourth. Normal is the
baseline default, and a package saved before today reads as Normal rather than
blank - blank would sort and filter as an invisible fourth level.
Sorted by ESCALATION, not alphabetically. High/Normal/Urgent would put the
most urgent last, which is the one thing the column exists to prevent. The
probe asserts the order AND that it is not the sorted order.
Colour is never the only signal. The label is always rendered; the three
differ by fill as well as by hue (outline / amber / red). Every value is a
canonical token - X7's warning is that without one source of truth for colour,
Normal/High/Urgent gets four implementations. 0 colour literals in the
creator's stylesheet, asserted rather than assumed.
Independent of status: the probe changes priority and checks the status radio
did not move, then checks collectPackage reports the new priority with the old
status.
Sorting, and what "including with empty values" had to decide
EMPTIES LAST, in both directions. Ascending by P6 activity means "the ones
with an activity, in order, then the ones without", because nobody sorts by a
column in order to look at the rows that have nothing in it. Reversing the
direction reverses the filled rows and leaves the blanks where they are. The
probe checks both directions and that no row is lost either way.
A non-numeric value in a numeric column is neither empty nor a number; it
sorts after the numbers rather than as NaN, which compares false against
everything and leaves the order undefined.
Every sortable header is a real <button> inside its <th>, so it is in the tab
order and Enter/Space work without being wired up. The direction is exposed
through aria-sort on the th as well as drawn as an arrow, and the sorted
column is bold - three channels (C1). Gates and the actions column are not
sortable and therefore are not offered as buttons.
html/wp-creation-index.html two P6 fields, the priority select
html/wp-creation-app.js DASH_COLUMNS, dashSortRows, dashHeaderCells,
WP_PRIORITIES, wpPriorityOf, priorityPill
html/wp-creation-styles.css .dash-sort, .prio
tests/generalinfo_check.py new - 49 checks
Done when — CR-001
[x] both fields exist, persist, and survive a reload (saved, reloaded, reopened)
[x] Activity ID renders next to Due Date on the detail view
[x] the column sorts correctly, including with empty values
[x] both fields appear on the PDF export
[x] the fields respect the CR-006 section toggles
Done when — CR-003
[x] exactly three values; Normal is the default on a new work package
[x] the dashboard filters and sorts by priority
[x] priority colours come from canonical tokens; no raw hex added
[x] colour is not the only signal - the label is always present
[x] priority prints on the PDF export
[x] changing priority does not alter status
No migration. Both fields live in the work package's JSON data blob, which is
where every other per-package field lives; nothing in server/models.py changed.
Verified one at a time
generalinfo_check 49/49 new
browser_check 71/71
sections_check 88/88
a11y 22/22
pipeline 43/43
url_state 23/23
aggregates 16/16
f_items F1-F5 FIXED, F6 REPRODUCES (T7.2)
One note on running these: two of the runs above aborted with "browser would not
start after 3 attempts". That is the documented back-to-back port exhaustion,
not a code fault - both passed after a pause. The brief warns about it and it is
real.
Question for the PR, per CLAUDE.md: priority has no effect on anything yet - it
does not sort the board by default, does not affect release readiness, and does
not appear on the field view. It is a label the planner sets and a filter the
dashboard offers. If Urgent is meant to DO something, that is a separate item.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
