Mike Swanson
b153ff158b
New /self-check skill: each machine probes its own ClaudeTools harness wiring (identity.json paths, required tooling, settings.json hooks, skill/command/script set, vault decrypt, coord/Gitea connectivity, Ollama capability tier) and grades RED/AMBER/GREEN against a checked-in provisional baseline manifest. - Capability-tier model: architectural/OS/hardware differences (e.g. no local Ollama) select a fallback ruleset instead of failing. - Duplicate detection: flags command/skill names that diverge between the repo and ~/.claude (the "same /cmd, different behaviour" cross-machine bug); CRLF-only diffs ignored. - Memory check: index + orphan detection, plus a model-driven semantic pass for memories that contradict identity/settings. - V1 is a census tool: --publish writes a per-machine census to coord (component selfcheck_<host>); fanout requests the fleet to self-check + self-remediate + re-publish; aggregate derives the proposed baseline. No machine ever fixes another. Reviewed twice by the Code Review Agent; three CRITICAL coord-API bugs and the CRLF false-WARN found and fixed, verified live against the coord API. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
69 lines
3.6 KiB
Markdown
69 lines
3.6 KiB
Markdown
# Self-Check Baseline
|
|
|
|
`manifest.json` is the **single source of truth** for how a ClaudeTools machine
|
|
should be wired. Every machine's `/self-check` grades itself against this file.
|
|
It is checked into the repo and syncs to all workstations via Gitea, so updating
|
|
it here updates the standard for the whole fleet.
|
|
|
|
## Why a checked-in manifest (the "how do we set a baseline" answer)
|
|
|
|
The fleet has architectural differences — Windows/macOS/Linux, amd64/arm64, boxes
|
|
with and without a local GPU for Ollama. We still want every machine to *behave*
|
|
the same. A checked-in manifest gives us that:
|
|
|
|
- **Required everywhere** lives in `required_*` keys. Missing = a real failure on
|
|
any machine, regardless of OS.
|
|
- **Allowed-to-differ** lives in `capability_tools` + `capability_rules`. A capability
|
|
being absent is never a failure — it selects a *fallback ruleset* so the machine
|
|
knows how to behave without it (the canonical example: no local Ollama → use the
|
|
remote endpoint; if that is down too, route Tier-0 work to haiku instead of
|
|
blocking on it).
|
|
|
|
`identity.json` (per-machine, gitignored) carries the machine's actual coordinates
|
|
and capabilities. The manifest says what's required; identity says where things are
|
|
and what this box can do; the probe reconciles the two.
|
|
|
|
## How the baseline gets built (V1 census → ratified baseline)
|
|
|
|
The current `manifest.json` is **provisional** — generated from one known-good
|
|
machine (GURU-5070, 2026-06-02). It has not been confirmed against the fleet.
|
|
The build sequence:
|
|
|
|
1. `self-check.sh fanout` — ask every active instance to report.
|
|
2. Each machine runs `self-check.sh --publish` — publishes its census to coord as
|
|
component `selfcheck_<host>`.
|
|
3. `self-check.sh aggregate` — reads them all back and proposes:
|
|
- items present on **all** reporting machines → **required everywhere** candidates,
|
|
- items present on **some** machines → **capability-gated** candidates.
|
|
4. Mike reviews the proposal and edits this `manifest.json` to ratify it, then
|
|
flips `"status": "provisional"` to `"ratified"` and commits.
|
|
|
|
Until ratified, treat "extra"/"missing" skill and command findings as **candidates**,
|
|
not gospel.
|
|
|
|
## Manifest structure
|
|
|
|
| Key | Meaning |
|
|
|-----|---------|
|
|
| `schema_version`, `status` | manifest version; `provisional` or `ratified`. |
|
|
| `required_tools[]` | tools every machine must have on PATH (`name`, `why`). Missing = FAIL. |
|
|
| `required_python.any_of[]` | acceptable python launchers (`py`/`python3`/`python`). |
|
|
| `capability_tools[]` | optional tools; presence is INFO and toggles a `capability`. |
|
|
| `required_identity_fields[]` | dotted identity.json paths that must be set. |
|
|
| `required_scripts[]`, `required_hook_files[]` | repo files that must exist (+ executable). |
|
|
| `required_settings_hooks[]` | hooks that must be wired in settings.json (`event`, `command_contains`, `why`). |
|
|
| `git` | expected remote host, internal IP, post-commit-hook expectation. |
|
|
| `skills[]`, `commands[]` | the canonical skill dirs / command files. |
|
|
| `connectivity[]` | endpoints to probe (`required` ones FAIL if unreachable). |
|
|
| `capability_rules{}` | per-capability fallback behavior (the "different rules" for different hardware). |
|
|
|
|
## Editing rules
|
|
|
|
- Add a **required** item only when it should hold on *every* machine, every OS.
|
|
If a Windows box legitimately can't have it, it's a capability, not a requirement.
|
|
- Every `capability_tools` entry needs a story for what to do without it — encode
|
|
it in `capability_rules` (or reference an existing tier) so the probe can print
|
|
the effective ruleset.
|
|
- Keep paths repo-relative and forward-slashed.
|
|
- After editing: commit + `/sync`. The fleet picks it up on next pull.
|