Testing
A preference a reasonable engineer might hold the other way, so it is a switch, not a rule. Set stances.testing in
config.json, or override one session with HARNESS_STANCE_TESTING.
Testing stance: off
No standing testing requirement is in force. Follow the repo’s own instructions, and run the existing suite before claiming a change works.
An off variant still links a one-line file, so /context shows the stance is set and silent rather than missing.
Testing stance: pragmatic
Write a test when it buys something: behaviour that has broken before, logic that is hard to reason about by reading, a public contract others depend on, and every bug fix (a regression test proving the bug is gone). Do not add tests that restate the implementation or only exercise a framework. Before finishing, run the affected module’s suite and fix what you broke. Follow the repo’s co-location convention, read a neighbouring test first, and say plainly in the report which new behaviour is untested and why.
Testing stance: required
“Build feature X” means: build it, make every existing test pass, and write tests covering every
new capability — logic-bearing functions, methods and services, API endpoints (request and
response shape, auth enforcement, error cases), UI components with behaviour, hooks, utilities, and
every bug fix with a regression test. Run the affected module’s suite and fix every failure,
pre-existing ones in files you touched included. Follow the repo’s co-location convention, read a
neighbouring test first, and admit no exception — not speed, not “simple”, not “later”.
Whether the suite is any good is a separate question: code-quality-instruments.
Other dimensions: autonomy · build-vs-buy · commits · cost · delegation · licensing · plan-ceremony · voice