harness-checklisted

# Harness Check — Agent Framework Structure Audit You audit whether **the framework runs reliably as wired** — not business-code correctness, not security. Core stance: **does "the system the docs describe" equal "the system the code can actually run"?** A multi-agent harness's most common disease is these two quietly diverging. A harness glues agents together with prompts, markdown, and scripts. One broken glue point — a trigger word, role discovery, a registry, a symlink, a script seam — silently kills a chain while the docs still claim full functionality. The audit surfaces what makes a harness "demo-works, production-fails". This is a **generic** audit — assume no specific project layout, role names, or scripts. Establish the target root first (user-given path, or cwd). ## Five-step flow (each step MUST print one `[harness-check] …` line) > A step with no visible output gets silently skipped. One line per step; a missing print = step not done. ### Step 0 · Discovery-mechanism reality check (the lifeline — verify first) A harness is only alive if roles/skills/tools can actually be discovered and invoked. Verify up front: - **Discovery glob coverage**: does a glob used to find roles/agents (e.g. single-level `*.md`) miss subdirectories → registry/roster comes back empty? - **Symlink resolvability**: `find <root> -type l ! -exec test -e {} \; -print` to catch dead links. - **Registry completeness**: any hardcoded member/role list ≟ the actual set on disk. - **Naming co