References
Each source here changed something in the code.
The harness
Böckeler, Harness engineering for coding agent users (martinfowler.com), is the foundation: guides are feedforward, sensors are feedback, and both are computational (deterministic) or inferential (model judgment). Execution: computational | inferential on every sensor is this taxonomy made literal.
Böckeler, Maintainability sensors for coding agents (martinfowler.com), cost three commits. First, "the agent reliably ignores sensor checks unless hardwired via hooks or extensions", and markdown guides alone are "quite unreliable". code-conventions.md asked the agent to run the linter; code-maintainability now runs it.
Second, her warning about "a false sense of security and an illusion of quality". harness-kit had built that: sensors calling themselves deterministic hard gates while checking nothing, and a quality log recording passed on every run. That produced exit 3 (inferential, never a pass) and exit 2 (a computational sensor with no wired check is broken).
Third, the complexity limits (max arguments, file length, function length, cyclomatic complexity) "weren't even active in ESLint's default preset". Ruff is the same. They are now set in pyproject.toml, CI runs them, and they found real debt at once. Her warning about feedback overload, "sending it into a spiral of over-engineered refactorings", is why the one violation found is a named per-file ignore with its reason written down, instead of a refactor of untested code.
Fowler, Agentic Programming (martinfowler.com): humans stop typing code and review it, "still responsible for what the software does". That is why the two human gates sit where they do.
Evals and the judge
Wataoka et al., Self-Preference Bias in LLM-as-a-Judge, and Panickssery et al., LLM Evaluators Recognize and Favor Their Own Generations, show that a judge rates its own family's output higher than humans do; a fresh evaluator does not fix this. Hence /hk:eval jev: Jev by TypeSafe AI is a different family, which reduces the bias, it does not remove it.
CheckEval and TICK show that atomic yes/no checklists raise judge agreement. That is why every rubric dimension now carries - check: and - absent: lines and scores the share of checks met.
Jung et al., Trust or Escalate, is why a Jev run escalates to the Claude evaluator when unsure answers could flip pass or fail. The Jev 1.13 guidance (one judgment per question, no counting, filter state) shaped how checks are written and why the artifact is sent split by section.
Husain, Using LLM-as-a-Judge for evaluation and Your AI product needs evals, argues that uncalibrated 1-10 scales mean different things to different graders and that trust comes from measured agreement with human labels, about 100 per failure mode. harness-kit has no human labels yet; 8.0 is a convention, not a calibrated boundary, as pipeline-pattern.md states. The jev-judge.jsonl log starts that set, and eval-score.py makes the arithmetic computed instead of judged.
Testing the harness itself
harness-kit gated every artifact it produced and had nothing gating itself: no tests, no CI, no linter. A one-word heading mismatch disabled about 30 section assertions across three sensors and nobody noticed. The test that catches it is four lines and runs over every sensor, including ones not written yet. The harness needs a harness.
The engineering canon (system-architect)
The system design method draws on Kleppmann (Designing Data-Intensive Applications), Jeff Dean's latency numbers, Vogels on eventual consistency, Helland on data on the outside versus inside, Nygard (Release It!) on stability patterns, and Ousterhout (A Philosophy of Software Design) on complexity. These shape the design rubric and the ten staff questions.
See also
Harness Engineering, Sensors, Evals, Agent Pipelines.
This page mirrors References in the wiki. Edit it there.