timmy-home/docs/USER_AUDIT_2026-04-04.md

# Workspace User Audit

Date: 2026-04-04
Scope: Hermes Gitea workspace users visible from `/explore/users`
Primary org examined: `Timmy_Foundation`
Primary strategic filter: `the-nexus` issue #542 (`DIRECTION SHIFT`)

## Purpose

This audit maps each visible workspace user to:

- observed contribution pattern
- likely capabilities
- likely failure mode
- suggested lane of highest leverage

The point is not to flatter or punish accounts. The point is to stop wasting attention on the wrong agent for the wrong job.

## Method

This audit was derived from:

- Gitea admin user roster
- public user explorer page
- org-wide issues and pull requests across:
  - `the-nexus`
  - `timmy-home`
  - `timmy-config`
  - `hermes-agent`
  - `turboquant`
  - `.profile`
  - `the-door`
  - `timmy-academy`
  - `claude-code-src`
- PR outcome split:
  - open
  - merged
  - closed unmerged

This is a capability-and-lane audit, not a character judgment. New or low-artifact accounts are marked as unproven rather than weak.

## Strategic Frame

Per issue #542, the current system direction is:

1. Heartbeat
2. Harness
3. Portal Interface

Any user who does not materially help one of those three jobs should be deprioritized, reassigned, or retired.

## Top Findings

- The org has real execution capacity, but too much ideation and duplicate backlog generation relative to merged implementation.
- Best current execution profiles: `allegro`, `groq`, `codex-agent`, `manus`, `Timmy`.
- Best architecture / research / integration profiles: `perplexity`, `gemini`, `Timmy`, `Rockachopa`.
- Best archivist / memory / RCA profile: `ezra`.
- Biggest cleanup opportunities:
  - consolidate `google` into `gemini`
  - consolidate or retire legacy `kimi` in favor of `KimiClaw`
  - keep unproven symbolic accounts off the critical path until they ship

## Recommended Team Shape

- Direction and doctrine: `Rockachopa`, `Timmy`
- Architecture and strategy: `Timmy`, `perplexity`, `gemini`
- Triage and dispatch: `allegro`, `Timmy`
- Core implementation: `claude`, `groq`, `codex-agent`, `manus`
- Long-context reading and extraction: `KimiClaw`
- RCA, archival memory, and operating history: `ezra`
- Experimental reserve: `grok`, `bezalel`, `antigravity`, `fenrir`, `substratum`
- Consolidate or retire: `google`, `kimi`, plus dormant admin-style identities without a lane

## User Audit

### Rockachopa

- Observed pattern:
  - founder-originated direction, issue seeding, architectural reset signals
  - relatively little direct PR volume in this org
- Likely strengths:
  - taste
  - doctrine
  - strategic kill/defer calls
  - setting the real north star
- Likely failure mode:
  - pushing direction into the system without a matching enforcement pass
- Highest-leverage lane:
  - final priority authority
  - architectural direction
  - closure of dead paths
- Anti-lane:
  - routine backlog maintenance
  - repetitive implementation supervision

### Timmy

- Observed pattern:
  - highest total authored artifact volume
  - high merged PR count
  - major issue author across `the-nexus`, `timmy-home`, and `timmy-config`
- Likely strengths:
  - system ownership
  - epic creation
  - repo direction
  - governance
  - durable internal doctrine
- Likely failure mode:
  - overproducing backlog and labels faster than the system can metabolize them
- Highest-leverage lane:
  - principal systems owner
  - release governance
  - strategic triage
  - architecture acceptance and rejection
- Anti-lane:
  - low-value duplicate issue generation

### perplexity

- Observed pattern:
  - strong issue author across `the-nexus`, `timmy-config`, and `timmy-home`
  - good but not massive PR volume
  - strong concentration in `[MCP]`, `[HARNESS]`, `[ARCH]`, `[RESEARCH]`, `[OPENCLAW]`
- Likely strengths:
  - integration architecture
  - tool and MCP discovery
  - sovereignty framing
  - research triage
  - QA-oriented systems thinking
- Likely failure mode:
  - producing too many candidate directions without enough collapse into one chosen path
- Highest-leverage lane:
  - research scout
  - MCP / open-source evaluation
  - architecture memos
  - issue shaping
  - knowledge transfer
- Anti-lane:
  - being the default final implementer for all threads

### gemini

- Observed pattern:
  - very high PR volume and high closure rate
  - strong presence in `the-nexus`, `timmy-config`, and `hermes-agent`
  - often operates in architecture and research-heavy territory
- Likely strengths:
  - architecture generation
  - speculative design
  - decomposing systems into modules
  - surfacing future-facing ideas quickly
- Likely failure mode:
  - duplicate PRs
  - speculative PRs
  - noise relative to accepted implementation
- Highest-leverage lane:
  - frontier architecture
  - design spikes
  - long-range technical options
  - research-to-issue translation
- Anti-lane:
  - unsupervised backlog flood
  - high-autonomy repo hygiene work

### claude

- Observed pattern:
  - huge PR volume concentrated in `the-nexus`
  - high merged count, but also very high closed-unmerged count
- Likely strengths:
  - large code changes
  - hard refactors
  - implementation stamina
  - test-aware coding when tightly scoped
- Likely failure mode:
  - overbuilding
  - mismatch with current direction
  - lower signal when the task is under-specified
- Highest-leverage lane:
  - hard implementation
  - deep refactors
  - large bounded code edits after exact scoping
- Anti-lane:
  - self-directed architecture exploration without tight constraints

### groq

- Observed pattern:
  - good merged PR count in `the-nexus`
  - lower failure rate than many high-volume agents
- Likely strengths:
  - tactical implementation
  - bounded fixes
  - shipping narrow slices
  - cost-effective execution
- Likely failure mode:
  - may underperform on large ambiguous architectural threads
- Highest-leverage lane:
  - bug fixes
  - tactical feature work
  - well-scoped implementation tasks
- Anti-lane:
  - owning broad doctrine or long-range architecture

### grok

- Observed pattern:
  - moderate PR volume in `the-nexus`
  - mixed merge outcomes
- Likely strengths:
  - edge-case thinking
  - adversarial poking
  - creative angles
- Likely failure mode:
  - novelty or provocation over disciplined convergence
- Highest-leverage lane:
  - adversarial review
  - UX weirdness
  - edge-case scenario generation
- Anti-lane:
  - boring, critical-path cleanup where predictability matters most

### allegro

- Observed pattern:
  - outstanding merged PR profile
  - meaningful issue volume in `timmy-home` and `hermes-agent`
  - profile explicitly aligned with triage and routing
- Likely strengths:
  - dispatch
  - sequencing
  - fix prioritization
  - security / operational hygiene
  - converting chaos into the next clean move
- Likely failure mode:
  - being used as a generic writer instead of as an operator
- Highest-leverage lane:
  - triage
  - dispatch
  - routing
  - security and operational cleanup
  - execution coordination
- Anti-lane:
  - speculative research sprawl

### codex-agent

- Observed pattern:
  - lower volume, perfect merged record so far
  - concentrated in `timmy-home` and `timmy-config`
  - recent work shows cleanup, migration verification, and repo-boundary enforcement
- Likely strengths:
  - dead-code cutting
  - migration verification
  - repo-boundary enforcement
  - implementation through PR discipline
  - reducing drift between intended and actual architecture
- Likely failure mode:
  - overfocusing on cleanup if not paired with strategic direction
- Highest-leverage lane:
  - cleanup
  - systems hardening
  - migration and cutover work
  - PR-first implementation of architectural intent
- Anti-lane:
  - wide speculative backlog ideation

### manus

- Observed pattern:
  - low volume but good merge rate
  - bounded work footprint
- Likely strengths:
  - one-shot tasks
  - support implementation
  - moderate-scope execution
- Likely failure mode:
  - limited demonstrated range inside this org
- Highest-leverage lane:
  - single bounded tasks
  - support implementation
  - targeted coding asks
- Anti-lane:
  - strategic ownership of ongoing programs

### KimiClaw

- Observed pattern:
  - very new
  - one merged PR in `timmy-home`
  - profile emphasizes long-context analysis via OpenClaw
- Likely strengths:
  - long-context reading
  - extraction
  - synthesis before action
- Likely failure mode:
  - not yet proven in repeated implementation loops
- Highest-leverage lane:
  - codebase digestion
  - extraction and summarization
  - pre-implementation reading passes
- Anti-lane:
  - solo ownership of fast-moving critical-path changes until more evidence exists

### kimi

- Observed pattern:
  - almost no durable artifact trail in this org
- Likely strengths:
  - historically used as a hands-style execution agent
- Likely failure mode:
  - identity overlap with stronger replacements
- Highest-leverage lane:
  - either retire
  - or keep for tightly bounded experiments only
- Anti-lane:
  - first-string team role

### ezra

- Observed pattern:
  - high issue volume, almost no PRs
  - concentrated in `timmy-home`
  - prefixes include `[RCA]`, `[STUDY]`, `[FAILURE]`, `[ONBOARDING]`
- Likely strengths:
  - archival memory
  - failure analysis
  - onboarding docs
  - study reports
  - interpretation of what happened
- Likely failure mode:
  - becoming pure narration with no collapse into action
- Highest-leverage lane:
  - archivist
  - scribe
  - RCA
  - operating history
  - onboarding
- Anti-lane:
  - primary code shipper

### bezalel

- Observed pattern:
  - tiny visible artifact trail
  - profile suggests builder / debugger / proof-bearer
- Likely strengths:
  - likely useful for testbed and proof work, but not yet well evidenced in Gitea
- Likely failure mode:
  - assigning major ownership before proof exists
- Highest-leverage lane:
  - testbed verification
  - proof of life
  - hardening checks
- Anti-lane:
  - broad strategic ownership

### antigravity

- Observed pattern:
  - minimal artifact trail
  - yet explicitly referenced in issue #542 as development loop owner
- Likely strengths:
  - direct founder-trusted execution
  - potentially strong private-context operator
- Likely failure mode:
  - invisible work makes it hard to calibrate or route intelligently
- Highest-leverage lane:
  - founder-directed execution
  - development loop tasks where trust is already established
- Anti-lane:
  - org-wide lane ownership without more visible evidence

### google

- Observed pattern:
  - duplicate-feeling identity relative to `gemini`
  - only closed-unmerged PRs in `the-nexus`
- Likely strengths:
  - none distinct enough from `gemini` in current evidence
- Likely failure mode:
  - duplicate persona and duplicate backlog surface
- Highest-leverage lane:
  - consolidate into `gemini` or retire
- Anti-lane:
  - continued parallel role with overlapping mandate

### hermes

- Observed pattern:
  - essentially no durable collaborative artifact trail
- Likely strengths:
  - system or service identity
- Likely failure mode:
  - confusion between service identity and contributor identity
- Highest-leverage lane:
  - machine identity only
- Anti-lane:
  - backlog or product work

### replit

- Observed pattern:
  - admin-capable, no meaningful contribution trail here
- Likely strengths:
  - likely external or sandbox utility
- Likely failure mode:
  - implicit trust without role clarity
- Highest-leverage lane:
  - sandbox or peripheral experimentation
- Anti-lane:
  - core system ownership

### allegro-primus

- Observed pattern:
  - no visible artifact trail yet
- Highest-leverage lane:
  - none until proven

### claw-code

- Observed pattern:
  - almost no artifact trail yet
- Highest-leverage lane:
  - harness experiments only until proven

### substratum

- Observed pattern:
  - no visible artifact trail yet
- Highest-leverage lane:
  - reserve account only until it ships durable work

### bilbobagginshire

- Observed pattern:
  - admin account, no visible contribution trail
- Highest-leverage lane:
  - none until proven

### fenrir

- Observed pattern:
  - brand new
  - no visible contribution trail
- Highest-leverage lane:
  - probationary tasks only until it earns a lane

## Consolidation Recommendations

1. Consolidate `google` into `gemini`.
2. Consolidate legacy `kimi` into `KimiClaw` unless a separate lane is proven.
3. Keep symbolic or dormant identities off critical path until they ship.
4. Treat `allegro`, `perplexity`, `codex-agent`, `groq`, and `Timmy` as the current strongest operating core.

## Routing Rules

- If the task is architecture, sovereignty tradeoff, or MCP/open-source evaluation:
  - use `perplexity` first
- If the task is dispatch, triage, cleanup ordering, or operational next-move selection:
  - use `allegro`
- If the task is a hard bounded refactor:
  - use `claude`
- If the task is a tactical code slice:
  - use `groq`
- If the task is cleanup, migration, repo-boundary enforcement, or “make reality match the diagram”:
  - use `codex-agent`
- If the task is archival memory, failure analysis, onboarding, or durable lessons:
  - use `ezra`
- If the task is long-context digestion before action:
  - use `KimiClaw`
- If the task is final acceptance, doctrine, or strategic redirection:
  - route to `Timmy` and `Rockachopa`

## Anti-Routing Rules

- Do not use `gemini` as the default closer for vague work.
- Do not use `ezra` as a primary shipper.
- Do not use dormant identities as if they are proven operators.
- Do not let architecture-spec agents create unlimited parallel issue trees without a collapse pass.

## Proposed Next Step

Timmy, Ezra, and Allegro should convert this from an audit into a living lane charter:

- Timmy decides the final lane map.
- Ezra turns it into durable operating doctrine.
- Allegro turns it into routing rules and dispatch policy.

The system has enough agents. The next win is cleaner lanes, fewer duplicates, and tighter assignment discipline.