Seeding the name pick with the role index (0..n) started every crew at the top
of the pool and took the next free names, so the first mission after the switch
to per-mission crews hired Aarav, Abebe, Adaora, Adrian, Agnieszka. Unique and
correct, and transparently generated.
Seed from the claw's own uuid instead. UUIDv7 puts its random bytes LAST — the
leading bytes are a timestamp, which would cluster the same way — so the tail
is what spreads five picks across the whole pool.
Co-Authored-By: Claude Opus 5 <[email protected]>
Reverses the reuse added earlier, by operator decision. Reuse hired the
existing claw for a (template, slot) so the roster stayed at one team — but it
also meant every mission was staffed by the same five names, and the workforce
view showed one crew repeated down the page with nothing to tell the missions
apart. Distinct crews read better than a bounded roster.
The cost is the one reuse existed to avoid: claws are lifecycle='permanent'
and nothing reaps them until their MISSION is deleted, so the roster now grows
by the team size per mission. `agent_names::pick` keeps names unique
workspace-wide and degrades to a numeric suffix rather than colliding, and the
pool grew from 70 to 200+ given names so a workspace runs ~35 missions before
the first repeat. `reusable_claw` is kept in cm-db with its tests: this policy
has now flipped twice and the query is the hard part.
Also revives a test that had silently stopped running. An edit stranded
`runtime_data_is_scoped_to_one_mission`'s `#[test]` above its neighbour,
leaving two attributes there and none here — so the neighbour ran TWICE and
this one never ran at all. The total test count was unchanged by the fix
(291 before and after), which is exactly why a count is not evidence: rustc
had said "duplicated attribute" and "function is never used" all along, and
both read as ordinary warnings. The test guards per-mission `/zeroclaw-data`
isolation, i.e. one mission reading another's door token.
Co-Authored-By: Claude Opus 5 <[email protected]>
Three things, all visible on the agents page.
**The roster looked like it was multiplying.** The sidebar flattened
orgs → companies → teams → agents, which renders a claw once per TEAM it
belongs to. Claws are reused across missions now, so a crew of five that had
run five missions appeared as twenty-five rows of the same five people. The
data was right and the view was lying. `GET /api/workforce` returns the roster
grouped by mission, and the tree renders each mission as a collapsible group,
so the repetition means something: the same colleague under each mission they
staffed. Claws on no mission come back under "Not on a mission" rather than
vanishing. The root now counts DISTINCT people, not rows.
**Agents were named after their jobs.** A team came back as planner, coder,
tester, reviewer, committer — the UI showed the same word twice (name on top,
role beneath) and the roster read as a stack of job tickets. New claws get a
given name from a deliberately wide pool (Amara, Vijay, Tomasz, Meredith…),
unique against the workspace roster AND within the team being minted. The role
is untouched in `job_title`, which is what the mission machinery binds on:
team_members.role_slot and the topology node carry the slot, so nothing
downstream keys off the display name. A reused claw keeps the name it had.
**Two latent reap bugs found while investigating a leak that was not one.**
Containers of completed missions are removed by `spawn_sweeper` after a
30-minute grace, and it works — an earlier report of leaking containers was me
reading that deliberate grace as a bug. But:
- the sweeper cleared the runtime binding even when teardown FAILED, and it
selects on `runtime_endpoint IS NOT NULL`. One transient docker error would
therefore hide a surviving container from the only thing that would retry
it, permanently. It now asks docker whether the container actually
survived: gone means clear, still there means keep the binding and retry —
which closes the orphan path without reintroducing the infinite retry the
original comment was guarding against.
- `set_runtime_binding` discarded rows_affected, so a mismatched workspace
updated nothing and returned Ok. The binding is how the sweeper finds a
container; a silent no-op there leaks one with no record of anything wrong.
Co-Authored-By: Claude Opus 5 <[email protected]>
