calls.jsonl records the call site's tag but not the lane.Role it was routed under, so a watched task step and an unwatched one are the same row #928

What is wrong

calllog.Record — the row every model call writes to ~/.aforge/logs/calls.jsonl —
carries a tag (the call site's own word for the errand) and does not carry the
lane.Role the call was actually routed under.

The role is the thing that decides how the call was routed: λ, the quality bar, the
exploration horizon and — the one a person feels — Visible, which is the whole of the
watched/unattended split. It is in the context at the moment of the call
(provider.WithRole), and it is dropped on the floor before the row is written.

So anything that reads the log back has to reconstruct it, and reconstruction is lossy
in a way that cannot be repaired from the file:

• RoleLeafAttached and RoleLeafUnattended write the same tag, task.
  internal/session's laneRole asks someoneIsWatching() at the moment of the call and
  nothing records the answer. A watched task step and an unwatched one are
  indistinguishable in the log, and they differ in exactly the field that decides whether
  a person's seconds were being spent.
• The tag vocabularies do not line up. internal/session/auxiliary.go writes
  string(role) for an internal/roles.Role; cmd/aforge/chat.go's errandContext
  writes the errand's name (title, distill, quorum, craft-params, …);
  internal/session/toolask.go writes tool:<tool>. Three vocabularies, one column,
  and the lane.Role that all three already had in hand is in none of them.

Replication

A stranger can run this with no private data:

go test ./cmd/aforge-replay/ -run TestEveryTagTheBuildWritesResolvesToARoleSomebodyDeclared -v

That law walks the tree for every tag the build can write and fails on one the replay's
callSiteRoles table does not name — it is the stopgap standing in for the missing
column, and it exists only because the column is missing. Delete a row from
cmd/aforge-replay/request.go's callSiteRoles and it goes red, naming the tag.

The join itself is roleOf in cmd/aforge-replay/request.go, whose doc comment says it
is "the first thing to delete when the role reaches the row".

Acceptance

End-to-end, through the door the product uses:

1. calllog.Record gains a role column (json:"role,omitempty"), filled from the call
   context the same way tag is (internal/provider/calllog.go's callTag, beside it).
2. An untagged test drives a real call through internal/provider with
   provider.WithRole(ctx, lane.RoleLeafAttached) and asserts the written JSON line
   carries "role":"leaf.attached" — not leaf.unattended, which is the reading every
   reader of the log is forced into today.
3. cmd/aforge-replay's roleOf and its whole callSiteRoles table are deleted, and
   TestEveryTagTheBuildWritesResolvesToARoleSomebodyDeclared with them; the replay reads
   row.Role directly. A mixed log (ten days of rows with no role) still replays — the
   old rows read as RoleUnknown and the report says how many.

Why it matters now

cmd/aforge-replay (#922) reports mean regret per role class over the real log, and the
watched half of that table is built on this guess. Its task numbers are a floor on
how bad a watched task step was and can never be a ceiling, and the report has to say so
instead of printing a number.

Evidence

PR #922, cmd/aforge-replay/request.go roleOf / callSiteRoles;
internal/calllog/calllog.go:125 (the tag field's own comment);
internal/session/auxiliary.go:196; cmd/aforge/chat.go:5795;
internal/session/toolask.go:121; docs/design/recovery/census-20260910.md §8 finding 9,
which is the last time the missing tag cost somebody an answer.

Drafted with CodeAF · reviewed and owned by the author