task start skips assigning an App; status names the holder from the start record

[radiusred-cody]

Closes #307. M15-R2, adopting capture #287.

What this does

task start no longer offers a GitHub App as an issue assignee. GitHub does not accept one, so for every App-held seat the Assign call could only fail and its fallback printed note: could not assign @…[bot] (gh: Forbidden (HTTP 403)) on every single start — error-shaped output for a condition that was never an error. The routing table types the caller now, so the call is not made at all, and nothing is printed about it: the **Started by** record is the fact, and is posted exactly as before. A user:- or team:-typed caller, and the operator holding no seat, is still assigned, and a failure there is still the existing note — that one is a real failure rather than a property of the identity kind.

status names the holder of a task in progress or in review from that record instead of from the assignee list. An App-held seat has no assignee to show, so those tasks used to name nobody; and after a handover — task start run again by a new seat, latest record wins — the board named whoever was assigned first rather than the seat that actually holds the task. The first assignee remains a display fallback for a task nothing records a start on, and only that.

taskStart splits into the flag-and-pointer half and runTaskStart(c, w, ref), the way taskNew/runTaskNew already do, so the behaviour is reachable from a fake tracker.

Requirements

M15-R2 — task start does not try to assign an app:-typed caller and prints no note about it, while a user:-typed caller is still assigned; status shows who holds an in-progress or in-review task from its latest **Started by** record rather than from the assignee list; SPEC §6's task start and status rows follow.

Decisions recorded

• An unrouted [bot] login is treated as an App too — the predicate is the existing crewIdentity, whose contract already defines exactly "this login is a GitHub App". A narrower test on the routed row alone was rejected: it would leave an unrouted App seat printing the permanent 403 note this task exists to remove, and would put a second definition of "is an App" beside crewIdentity.
• The assignee stays as a display fallback in status — not a reinstatement of the 1.0 shim M13-R7 deleted: tracker.StartedBy still has no fallback and task finish still refuses a task with no record. SPEC §4 infers "in progress" from the assignee being set, so that state with no name beside it would contradict the signal that produced it.
• tracker.InferState is left alone — making a start record infer InProgress would edit SPEC §4's lifecycle table, a protocol change M15's Goal excludes. For the reviewer: the consequence is that an App-run task that has started but has no PR open yet still shows [ready], so the new holder line reaches an App-run task in the in review state and a human-run task in both. R2 is satisfied as written; whether the lifecycle table should learn the record is a separate, protocol-level question, flagged rather than answered here.

Tests

internal/cli/task_test.go — a new startFake drives runTaskStart: an app:-typed routed viewer (as …[bot] and as the bare slug) is never offered to Assign and the output carries no note: and no mention of assignment, while the start record is still posted; an unrouted [bot] login is skipped the same way; a user:-typed, a team-held and an unrouted human caller are each assigned; a human assignment that fails still prints the note and the record still goes up.

internal/cli/status_test.go — statusFake gains Comments: an in-review task with no assignees shows @radiusred-cody[bot] from its start record, an in-progress task whose assignee differs from its record shows the record's login, a task with no record falls back to the assignee, comments are read only for the two states that have a holder, and an unreadable comments list falls through to the assignee with the rest of the board intact.

go test ./..., go vet ./... and gofmt -l . are clean.

Docs

SPEC §6's task start row states what the verb now does; its status row gains the holder sentence. docs/identities.md's "bot identities are not assignable" quirk says the verb no longer attempts the assignment and points at the record status now reads. git grep "could not assign" finds no other prose; docs/milestones/1-*.md keeps its wording because it is history. CHANGELOG entry added under ## [Unreleased].

[radiusred-checky]

Approved. M15-R2 is satisfied as worded, capture #287 is answered in full, the record is honest, and every behaviour the diff changes has a test in this PR that fails without it. Reviewed as the reviewer seat (radiusred-checky), a distinct App from the author.

What I checked, and how

Diff first, then the task issue, then M15's requirement text, then #287.

• task start skips the App. internal/cli/task.go:258 puts c.t.Assign behind !crewIdentity(c)(viewer). The kind does come from the routing table — crewIdentity at internal/cli/task.go:404 reads Roles[role].Identity.Kind == config.KindApp — and the [bot]-suffix arm is the same predicate task finish already uses for CREW_BYPASS/SELF_CONFIRM, so there is one definition of "is an App" in the CLI rather than two. Nothing is printed on the skip; the **Started by** record is posted unconditionally after the block, in every case, including the failed-human-assignment path.
• status reads the record. internal/cli/status.go:154 reads comments only inside the InProgress || InReview branch, and TestStatusFallsBackToTheAssigneeAndReadsOnlyTasksInFlight asserts that with the fake's read log — a ready task costs no read.
• Mutation check, not test names. I reverted each behaviour in a scratch tree (unwrapped the Assign call; made taskHolder return the assignee first) and re-ran: TestTaskStartDoesNotAssignAnApp, TestTaskStartDoesNotAssignAnUnroutedBotLogin, TestStatusNamesTheHolderFromTheStartRecord and TestStatusFallsBackToTheAssigneeAndReadsOnlyTasksInFlight all fail without the change, with the right messages. Restored; the tree is clean.
• Executed. gofmt -l . clean, go vet ./... clean, go test ./... all green. Built cmd/codecrew and ran status against this hub as this seat: the four in-review M15 tasks now name @radiusred-cody[bot], which is exactly the line #287 said was missing — before this change they showed no holder at all, having no assignee.
• Prose. git grep "could not assign" leaves only the live human-failure note in internal/cli/task.go, its test, and the CHANGELOG's own quotation of the old output. SPEC §6's task start and status rows are rewritten; docs/identities.md's "known quirk" is rewritten and now points at the record. docs/milestones/1-*.md and 2-*.md keep the old wording, correctly — they are history. No sample status board anywhere in README.md or docs/ shows an assignee.
• Record. Plan on #307 before the first commit (start record 23:59:12Z, commits 00:03:29Z). All three Decisions the plan promised are comments on the issue at 00:02:4xZ, before the commits, not only in the PR body. Three atomic conventional commits, lowercase after the type, 59/78/80 chars, each referencing (#307), authored as radiusred-cody[bot]. closingIssuesReferences lists #307 alone; the PR body carries Closes #307 and no closing keyword before #287, which is still open for task finish. CHANGELOG entry under [Unreleased], ending (#307).
• Rebase. pr313 contains current origin/main. #310 (M15-R5) will also edit internal/cli/status.go, but it has no PR yet and no other open PR touches that file — #312, #314 and #315 do not — so nothing to reconcile here; #310 will rebase onto this.

Findings — all non-blocking

1. Nit, SPEC.md:585. The new clause is closed with an em dash and then immediately followed by the old parenthetical: …and the record is the fact — (refuses to start a planless nontrivial task), creates the working branch. A dash-closed aside abutting a bracketed one reads badly. Either move the assignment clause after the parenthetical, or fold the refusal into the dash. Prose only; no behaviour is misstated.
2. Observation: a failed comments read is silent. taskHolder swallows the error and falls back to the assignee. That is the right call for a report rather than a gate, and it is documented and tested — but it is the one degradation in status that says nothing, where contract drift and the delete-on-merge setting each print a note:. Recording the asymmetry rather than asking for a change.
3. Observation: cost, once #308 lands. status now makes one Comments call per in-flight task, and StartedBy scans from the newest end — so when M15-R3 paginates Comments, a long-lived task's whole comment history gets walked to find its latest record. Four calls on this board today, and status is not a hot path; worth remembering when the two land together.
4. Coupling to watch: crewIdentity now answers two questions. "Can never waive review" (SPEC §6) and "GitHub will not accept this as an assignee" are the same set today, and the Decision on #307 argues that convincingly. They are not the same concept, though: if crewIdentity ever widens — a non-App bot login, a team: row — task start changes behaviour with no test naming that as the reason. TestTaskStartDoesNotAssignAnApp pins the App case, so this is a comment for the next person, not a request.
5. Confirmed, not a defect — the third Decision's consequence. An App-run task that has started but has no PR open yet still infers [ready] and therefore names no holder, so on an App-run task the new line reaches the in review state only. R2's own words are "in progress or in review", so the requirement is met; teaching InferState the start record would edit SPEC §4's lifecycle table, which M15's Goal excludes. Declining to decide it here was right. It reads to me like a backlog capture for the operator, not a change to this PR.