wednesday-harness

A reusable quality harness for Wednesday Solutions repos. It holds new code to a strict bar while grandfathering legacy debt, drives spec-first / test-first development, and consolidates everything behind one local command and one reusable CI workflow.

Extracted from the sage-n2 pilot (PR #1000). One source of truth, versioned, consumed by every repo.

Philosophy (the 30-second version)

• The ratchet. Rules are warnings globally (legacy is grandfathered), but the diff boundary is held to zero: only the lines a PR adds/changes must be clean. You never fight pre-existing debt.
• One gate. npm run eval runs everything the remote reviewers would flag — locally, before you push — so issues are caught early, not in N review rounds.
• Three review lenses. Correctness + security (agents/CI) · business outcome (human, vs the spec's intent) · engineering design (human, vs DESIGN_REVIEW).
• CI is authoritative. The gate runs from this pinned package/workflow in CI, so editing a local copy of a script can't pass the gate. Nothing bypasses eval.

What's in the box

| Path | What | |---|---| | scripts/ | the eval gate: eval.sh + check-pr-size, check-tests (TDD), lint-changed (diff-scoped lint/complexity), check-coverage (patch coverage), check-edge (Deno edge fns), ci-report.mjs | | config/ | harness.config.default.json (per-repo knobs) + base configs: eslint, jscpd, lint-staged, commitlint | | bin/ | wednesday-harness CLI dispatcher | | .github/workflows/eval.yml | reusable (workflow_call) CI gate | | agents/ | code-writer, code-reviewer, security-reviewer subagents | | skills/ | spec-driven, feature-discovery, wednesday-eval | | docs/ | the standards: WORKFLOW, QUALITY_GATES, TESTING, CONSTRAINTS, DESIGN_REVIEW, SESSION, DEVELOPMENT_FLOW, … | | templates/ | copy-in starting points: init.sh, PR template, feature_list example |

Quick start (consuming repo)

npm i -D @wednesday-solutions-ai/harness
cp node_modules/@wednesday-solutions-ai/harness/config/harness.config.default.json harness.config.json
# edit harness.config.json for this repo (base branch, edge dir, thresholds)

package.json:

"scripts": {
  "eval":   "wednesday-harness eval",
  "verify": "wednesday-harness eval && vitest run"
}

CI (.github/workflows/ci.yml):

jobs:
  quality:
    uses: wednesday-solutions/wednesday-harness/.github/workflows/eval.yml@v1
    with:
      node-version-file: .nvmrc
      run-edge: true   # if the repo has Supabase edge functions

Extend the base configs (e.g. eslint.config.js re-exports config/eslint.base.js), copy templates/ you want, and point CLAUDE.md/AGENTS.md at the docs/ standards.

harness.config.json

| Key | Meaning | |---|---| | baseBranches | merge-base candidates, in order (e.g. develop then main) | | prSize.warn / .fail | substantive-file thresholds (boilerplate excluded) | | coverage.min | patch-coverage % required on changed lines | | logicDirs | dirs whose new files require a test (TDD gate) | | edge.enabled / .dir | Deno edge-function ratchet + its directory | | exclude.fromSource / .boilerplate | regex paths excluded from source / size counting |

Local CLI

wednesday-harness eval [baseSha]   # the full gate
wednesday-harness tdd | lint | coverage | pr-size | edge | report

Why CI is authoritative (tamper-proof note)

A git submodule or a local copy distributes files but does not enforce — they're editable on disk. Enforcement comes from the reusable workflow running this harness from the pinned @v1 ref in CI. So local edits, --no-verify, or a weakened local script can't pass the gate; CI re-runs the real harness.

Versioning

Changes are made only here, reviewed, released as a semver tag. Consumers pin @v1 (workflow) / ^1 (package) and get latest within major; a breaking change is @v2, opted into deliberately.

License

MIT.