fix(neckbeard): resolve round-3 droid-review consistency findings

Four P3 findings on c5da020, all mechanical consistency defects:

- Notion fingerprint (notion.so/notion.site page links) added to the
  detection signal table and direct-evidence sentence, so the notion
  routing row is reachable by detection, not only by asking.
- Routing decision moved from packet group (a) to group (e): detected
  system + evidence basis stays provenance; which tooling skill operates
  the tracker is a specialist-selection record like every other routing
  entry.
- Empty-inventory branch relocated after the inventory step where it is
  actually decidable, and reconciled with Completion: empty inventory
  still delivers a report (phase 1) and bootstraps the packet.
- Position report gains assessment head SHA; step 5 derives current gate
  from the remaining checklist instead of reading a field the report
  never emitted.

Signed-off-by: Magnus Hedemark <magnus919@users.noreply.github.com>

neckbeard/references/position-assessment.md

@@ -45,10 +45,13 @@ Enter this mode only when all three hold:
 | No delivery packet exists for that work | No packet artifact accompanies the work; the prior run, if any, was outside this bundle |
 | The work is non-trivial enough to warrant the journey | Same threshold [../SKILL.md](../SKILL.md) applies before loading the journey |
 
-If a packet exists, use [delivery-packet.md](delivery-packet.md) resumability
-instead. If no artifacts exist at all, the honest position is **phase 1**: say
-so plainly and let the normal journey take over. An empty inventory is a
-finding, not a failure.
+If a delivery packet exists, use [delivery-packet.md](delivery-packet.md)
+resumability instead. The empty-inventory case ("no artifacts found") can only
+be determined after running step 2's inventory; when it holds, assessment
+still completes normally — deliver a position report stating phase 1 and
+perform the step-5 bootstrap, then let the normal journey take over. An empty
+inventory is a finding, not a failure, and it does not skip the report or the
+packet.
 
 ### Step 2 — Inventory the observable artifacts
 
@@ -124,7 +127,8 @@ execution. Format:
 
 ```
 current phase:        <n>-<phase-name>
-selected path:        <lightweight|full|refactor|high-risk> (re-selected, see below)
+selected path:        <lightweight|full|refactor|high-risk>
+assessment head SHA:  <git rev-parse HEAD at assessment time>
 satisfied gates:      <gate> @ <evidence pointer>; ...
 partial:              <gate/artifact> — <what remains>
 absent:               <gates with no evidence>
@@ -140,7 +144,12 @@ rule in [risk-authority-gates.md](risk-authority-gates.md).
 
 ### Step 5 — Bootstrap the packet
 
-Create a fresh delivery packet so subsequent operation has normal resumability:
+Create a fresh delivery packet so subsequent operation has normal resumability.
+Group (c) initialization derives its fields from the report: the current phase
+comes from the report's `current phase` field, the **current gate** is the
+first gate in the remaining checklist (or "none — awaiting next phase entry"
+if the checklist starts at a phase rather than a gate), and the recorded head
+SHA is the report's `assessment head SHA`.
 
 - Group (a) provenance records: engaged mid-flight, artifacts assessed, with
   the inventory pointers, and the tracking system identified during the

neckbeard/references/tracker-discovery.md

@@ -33,14 +33,15 @@ Run during phase 1 alongside provenance capture:
 
 | Signal | Points to |
 |---|---|
-| Issue/ticket URLs referenced by the change request (`…/issues/N`, `…/TICKET-123`, Linear `…/issue/TEAM-N`) | GitHub Issues / Jira / Linear respectively |
+| Issue/ticket URLs referenced by the change request (`…/issues/N`, `…/TICKET-123`, Linear `…/issue/TEAM-N`, Notion `notion.so`/`notion.site` page links) | GitHub Issues / Jira / Linear / Notion respectively |
 | `.jira-url`, Jira config files in the repository | Jira |
 | Team keys in ticket identifiers (`ENG-42` shape) with a non-GitHub tracker configured | Jira or Linear |
 | Project-management config directories (for example `.linear/`) or documented integrations in `CONTRIBUTING.md`, `AGENTS.md`, README | Whatever they name |
 
 2. **Check what the request itself references.** A change request arriving as a
-   Linear issue URL, a Jira ticket ID, or a GitHub issue number is direct
-   evidence for its own system. A bare team-key identifier (`ENG-42` shape) is
+   Linear issue URL, a Jira ticket ID, a GitHub issue number, or a Notion
+   page link (`notion.so` / `notion.site`) is direct evidence for its own
+   system. A bare team-key identifier (`ENG-42` shape) is
    **ambiguous** between Jira and Linear — treat it as a lead, not a verdict.
 
 3. **Weight the signals honestly.** The request's own references are strong
@@ -57,10 +58,12 @@ Run during phase 1 alongside provenance capture:
    work item? Record the answer as requester-provided provenance. Do not
    silently pick the system whose CLI happens to be installed.
 
-5. **Record in packet group (a):** detected/requested system, the evidence or
-   source of the answer (including when the basis is a requester confirmation),
-   and the routing decision below. Silent omission is prohibited like every
-   other intake field.
+5. **Record the findings:** detected/requested system with the evidence or
+   source of the answer (including when the basis is a requester confirmation)
+   goes in packet group (a) as provenance; the routing decision — which tooling
+   skill will operate tracker operations — is a specialist-selection decision
+   and is recorded in packet group (e), same as every other selected or skipped
+   skill. Silent omission is prohibited like every other intake field.
 
 ## Routing tracker operations