factory-retrolisted

# factory-retro The user's accompanying request is this workflow's argument string. Wherever these instructions refer to `$ARGUMENTS`, interpret it as that request. Turn measured friction into harness changes. Agents don't reliably remember what slowed them down, and asking them to write it up produces either nothing or noise. Three sources carry the evidence instead: ```bash factory friction $ARGUMENTS factory economics $ARGUMENTS factory ci $ARGUMENTS ``` Friction is what wasted the agents' _time_ inside a session; economics is what consumed _context and the usage window_ (context burn, cache thrash, zero-result runs); CI is the clock agents wait on _outside_ the session — workflow-scoped REST run watches in factory-merge/factory-ship sitting idle for however long GitHub Actions takes, per repo per workflow, with repeat-failure and slowdown-trend flags already computed. A repeat in any of the three is actionable — a tool that fails three runs running, a tool whose payloads dominate context burn, and an e2e job that's crept 40% slower over two weeks are all harness defects. **friction.mjs and economics.mjs need `~/.factory/logs/` transcripts, which only exist for runs the orchestrator itself dispatched.** Invoked directly from the harness — you running `/factory-retro` in a repo without going through orchestrator dispatch — there may be no matching transcripts; `friction.mjs` exits with "no transcripts" in that case, which is expected, not a failure, so don't chase it