Auditer les documents de compétences de l'agent pour slop.computer

You are auditing the agent skill docs for live.slop.computer.

The user invoked /skill. The agent skill is the markdown an external BYO-AI agent reads to drive the slop-computer desktop over the /v1 REST API. It's generated by pure functions in packages/relay/src/skill.ts (one INDEX + per-app SUB-SKILLS, served at GET /v1/skill and GET /v1/skill/:topic).

Your job: prove that everything a human can do in the desktop has an agent-reachable API, and that API is documented in the skill — then fix the gaps. Also enforce the doc shape: a lean index that points to self-contained, right-sized sub-skills.

This is a READ-WIDE, EDIT-NARROW task. Build the three inventories first, diff them, then touch skill.ts. Don't guess from memory — the app grows constantly; re-derive every inventory from current code.

---

The hard rules

1. Verify from code, never from memory. Apps/endpoints change every week. Re-extract all three inventories fresh each run. A skill doc that describes a renamed/removed endpoint is worse than a missing one.
2. Don't invent endpoints. If a human action has no REST mirror and no documented WS verb, that's a gap to report, not a route to hallucinate into the docs. Adding a new server route is an API-design decision — propose it and get the user's nod before editing index.ts. Doc-only fixes (an endpoint that already exists but isn't written up) you apply directly.
3. Keep the index lean. The index = orientation + per-room routing + always-available core endpoints (/v1/state, agent-token, cursor, click, chat) + the sub-skill directory. App specifics live in sub-skills, never the index. If you find app detail creeping into the index, move it down.
4. No oversized sub-skill. Soft cap ~220 lines of generated markdown per sub-skill (music + build are the known-large exceptions). If one balloons past that with genuinely separable concerns, split it into a new topic rather than letting it sprawl.
5. Three lists must agree. SKILL_TOPICS ↔ the index directory table ↔ the skillForTopic() router switch. A topic missing from any of the three is a bug. Every DEFAULT_APPS entry a human can act on should map to a topic (or be explicitly covered by an existing one).
6. Don't deploy. Compiling clean is the finish line here; shipping is /deploy's job.

---

Step 1: Build the three inventories (run the sweeps in parallel)

A. Human actions — what the frontend lets a person do

Sweep packages/nextjs/ for every interactive action that produces a relay call. Two channels:

• REST: fetch( / relay-client helpers hitting /v1/*, /auth/*, /admin/*. Grep the components, hooks, services.
• WS mesh verbs: messages the client sends — send({ type: ... }) in hooks/usePeerMesh.ts (the bulk live here), plus the separate browser-host socket in components/.../SharedBrowser.tsx.

Delegate this to an Explore agent — it's a broad fan-out across many component files. Ask it to group results by app/surface and report, per action: the action, the METHOD /path or {type:...} verb, and whether it's any-peer / host-only / god-mode-only. Tell it to pay special attention to surfaces that might lack a REST mirror: wagers/escrow (money games), the Hire/Leftclaw app, title-card overlay, QR, chyron, reactions, peer rename, scroll/preview/ui sync, camera/mic/screen publish, and the host control panel (broadcast/recording/kick/start/stop).

B. Relay API surface — what endpoints actually exist

From packages/relay/src/ (mostly index.ts):

cd packages/relay/src
# Routes — NOTE: registrations look like  app.post<{ Body: X }>("/path", ...)
# so the method and the "(" are separated by a <...> generic. Match it:
grep -rhoE "(app|fastify)\.(get|post|delete|put|patch)(<[^>]*>)?\(\s*[\"\`][^\"\`]+" . \
  | sed -E "s/.*\.(get|post|delete|put|patch)(<[^>]*>)?\(\s*[\"\`]/\1 /" \
  | awk '{print toupper($1)" "$2}' | sort -u
# ALSO catch multi-line registrations (path on the line AFTER the method):
grep -nA1 -E "(app|fastify)\.(get|post|delete|put|patch)(<[^>]*>)?\($" index.ts \
  | grep -E "\"/"
# Upload routes register via addContentTypeParser (image/octet/audio) —
# check those too: /v1/avatars, /v1/files, /v1/music/upload.

Then the WS verb handlers — the case "<verb>": arms in the /signal socket handler (search index.ts for case "), and the DEFAULT_APPS catalog (grep -n 'id: "' index.ts around the DEFAULT_APPS array). DEFAULT_APPS is the human-visible app list — every actionable app there needs skill coverage.

C. Documented surface — what the skill already says

# Endpoints the skill mentions:
grep -hoE "/(v1|auth|admin|music|files|avatars|apps)/[a-zA-Z0-9:_/<>-]+" skill.ts \
  | sed -E 's/<[^>]*>/:x/g' | sort -u
# Topics + the WS verb catalog table live in skill.ts too — read
# skillIndex(), skillWs(), and skillForTopic() in full.

---

Step 2: Diff into gap classes

Cross-reference A vs B vs C. Bucket every finding:

1. Human action, no agent API — exists in A, no REST in B and no documented WS verb in C. Hard gap. Either (a) the action is inherently human-only (camera/mic/screen publish, real signer keys) → the skill must explicitly say so, or (b) it's a real missing surface → propose a REST route (Rule 2: confirm before adding server code).
2. API exists, undocumented — in B, not in C. Doc gap. Add it to the right sub-skill, or stand up a new topic if it's a whole app.
3. Documented, but stale — in C, not in B. The endpoint was renamed or removed. Fix or delete the doc.
4. App with no topic — a DEFAULT_APPS entry whose surface isn't covered by any sub-skill. Almost always a missing sub-skill.
5. WS-only verb missing from the catalog — a case arm in B not in the skillWs() table. Add the row (with its REST mirror or WS-only).

For WS verbs that mirror a REST route, the skill's job is to say so in the skillWs() table — that counts as documented. WS-only verbs must be listed there and flagged WS-only with rationale.

---

Step 3: Structure & size hygiene

• Index audit: read the generated index (skillIndex). Is it just orientation + routing + core endpoints + directory? Move any app detail down into the sub-skill.
• Size audit: for each generator, eyeball the generated markdown length. Flag any sub-skill over ~220 lines (Rule 4). Propose a split.
• Source-file note: skill.ts itself is large (one file, all generators). If it's grown unwieldy, you may suggest splitting it into per-topic modules under skill/, but that's optional structural cleanup — don't do it as part of a routine audit unless asked.
• Consistency: confirm SKILL_TOPICS, the index directory table, and the skillForTopic() switch list the exact same set (Rule 5).

---

Step 4: Apply the fixes

• Doc-only gaps (classes 2, 3, 4, 5): edit skill.ts directly. For a new topic: write the skillX() generator (follow the existing shape — header() + slugNote() + sections), add it to SKILL_TOPICS, add a row to the index directory table, and wire it into skillForTopic(). Keep every example ?slug=-parameterized via slugStr(slug).
• Missing-API gaps (class 1b): propose the route shape and ask before adding it to index.ts (Rule 2). If approved, add the route, then its sub-skill docs.
• Inherently human-only (class 1a): add a one-line "humans only, here's why / here's the agent alternative" note in the relevant sub-skill (e.g. the "share your tab audio" recipe for DRM'd media).
• Match surrounding style. Don't reflow unrelated doc prose.

After editing, compile the relay:

cd packages/relay && yarn tsc --noEmit   # or the project's build script

Fix type errors you introduced. Don't touch unrelated failures — report them (Rule 1 spirit: don't fix code you didn't break).

---

Step 5: Report

Terse. A gap matrix and what you did:

• Table: surface → human action → agent API (REST path / WS verb / none) → doc status before → fix applied.
• Call out the hard gaps (class 1) separately — especially any you only reported (missing REST API) vs fixed (doc).
• Note structure findings: index still lean? any sub-skill over cap? all three lists in sync?
• End with: compiled clean (y/n), and "run /deploy to ship" if you changed skill.ts.

No walls of text. Findings, decisions, results.