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>

html/wp-creation-index.html

@@ -180,7 +180,26 @@
       <div class="field"><label>Distribution<span class="help-tip" data-tip="Who gets notified about this package. The project's Construction Manager is included by default and can be removed per package.">i</span></label>
         <div class="people-pick" id="pick_distribution"></div>
         <input type="hidden" id="wp_distribution"></div>
+      <!-- CR-003. Three levels, agreed live in the meeting, and there is no fourth.
+           Independent of status: a package can become Urgent after it is issued
+           without its status moving. -->
+      <div class="field"><label>Priority <span class="req">*</span><span class="help-tip" data-tip="How urgent this package is, independently of its status and its due date. Normal is the baseline; High and Urgent are exceptions and are meant to stay rare.">i</span></label>
+        <select id="wp_priority">
+          <option value="Normal" selected>Normal</option>
+          <option value="High">High</option>
+          <option value="Urgent">Urgent</option>
+        </select></div>
       <div class="field"><label>Due date</label><input type="date" id="wp_due"></div>
+      <!-- CR-001. Beside the due date on purpose: a date on a work package that
+           is not anchored to a schedule activity is a date floating on its own,
+           and the meeting placed the activity next to it for exactly that reason.
+           Free text — a validated lookup against an imported P6 activity list is
+           deferred (BL-000a) partly because the Micron schedule is being reworked,
+           and importing it now would import churn. -->
+      <div class="field"><label>P6 activity ID<span class="help-tip" data-tip="The Primavera P6 schedule activity this package delivers. Free text for now — a validated lookup against an imported activity list is deferred while the schedule is being reworked.">i</span></label>
+        <input type="text" id="wp_p6_id" placeholder="e.g. A1234"></div>
+      <div class="field"><label>P6 activity description</label>
+        <input type="text" id="wp_p6_desc" placeholder="what that activity covers"></div>
       <div class="field"><label>Specification section</label>
         <input type="text" id="wp_spec" readonly class="locked-field" placeholder="set on the WP type in the SOP">
         <div class="field-hint" id="spec-folder-link"></div></div>