rules/sycophancy.md references sycophancy-harness.py and other artifacts that don't exist

[FloweryScythe13]

Copied from downstream fork because this may depend on something from your other repos @assafkip , in which case me filling the gap downstream and merging back would be the wrong solution.

Summary

rules/sycophancy.md (pulled in via CLAUDE.md) describes an enforcement pipeline for a "sycophancy audit agent" that does not exist anywhere in this repo. Specifically, the rule states:

1. When the sycophancy audit agent runs (Phase 6), its output is verified by sycophancy-harness.py. If the harness disagrees, the harness wins.
2. If sycophancy-audit.json shows overall: "alert", the synthesizer MUST surface it as a dedicated section, not an FYI line.

None of the following exist in the repo:

• sycophancy-harness.py (anywhere)
• sycophancy-audit.json (anywhere, presumably a generated artifact, but no schema/generator either)
• A "sycophancy audit agent" / "Phase 6" skill or agent definition
• A "synthesizer" referenced as consuming the audit output

There's also a "Decision Origin Tagging" section in the same file requiring every decision logged to canonical/decisions.md to carry an origin tag ([USER-DIRECTED], [CLAUDE-RECOMMENDED -> APPROVED], etc.), plus a monthly audit on the 1st computing pi = approved / (approved + modified + rejected). canonical/decisions.md does not exist either, and there's no monthly-audit automation (cron/skill) anywhere in the repo.

Impact

Because this rule is loaded into every session via CLAUDE.md → rules/sycophancy.md, Claude is instructed to defer to a verification harness and decision log that don't exist. This is confusing during active investigation work (discovered while running an investigation case) and gives a false impression that sycophancy auditing is actively enforced when it isn't.

Suggested fix

Either:

1. Implement sycophancy-harness.py, the audit agent/skill, sycophancy-audit.json schema, and canonical/decisions.md scaffolding so the rule's claims are true, or
2. Update rules/sycophancy.md to describe these as aspirational/planned rather than enforced, until they're built.

[sophymarine]

That sycophancy-harness.py reference in rules/sycophancy.md looks like a control that never got wired into the repo. I’ve seen the same pattern when a policy file lands before the enforcement code. The doc describes the check, but the script and artefacts live somewhere else.

Two things usually cause it. Sometimes the rule file was copied from a parent repo where Phase 6 actually runs. Other times the harness was planned but never committed.

If it’s the first case, the rule probably needs a pointer to the upstream location plus the expected artefacts (sycophancy-audit.json shape, harness interface). If it’s the second, CI failing when CLAUDE.md names missing enforcement files would keep docs and code from drifting.