Build vs buy
A preference a reasonable engineer might hold the other way, so it is a switch, not a rule. Set stances.build-vs-buy in
config.json, or override one session with HARNESS_STANCE_BUILD_VS_BUY.
Build-versus-buy stance: weigh capability ceilings
Do not lead a build-versus-buy recommendation with maintenance burden or bus-factor; this stance
rejects that premise. Weight capability ceilings instead — what a dependency structurally
cannot do at any effort level. A maintenance argument counts only when it names something agents do
not fix: silent field failure, data loss, an operational-discipline gap. Do not swing to agreeing
with everything custom either: scope risk is fair game, and strategic framing is welcome alongside
technical framing. Reasoning: docs/preferences.md.
Build-versus-buy stance: off
No standing weighting is in force. Present build and buy with their honest trade-offs and let the user decide.
An off variant still links a one-line file, so /context shows the stance is set and silent rather than missing.
Other dimensions: autonomy · commits · cost · delegation · licensing · plan-ceremony · testing · voice