Follow-up to my-things-core#57 (my-things-core PR #126), which declares the service archetype (src/mythings/service-harness.md) but deliberately stops there — it's the "confirm before building" decision, not the retrofit itself.
What's left
- A
my-service-template repo (parallel to my-template) vendoring SERVICE_HARNESS.md instead of HARNESS.md, per service-harness.md's "per-service seams" section.
- Retrofit
my-server, my-telegram-bot, and my-dashboard (its serving mode) to vendor SERVICE_HARNESS.md instead of the tool HARNESS.md, since their actual invariants (long-running, not issue-triggered, health surface, may not open a PR) now have a canonical home that matches what they actually are.
- Confirm each of the three still passes its own drift-check test against the new canonical file, and update any doc that currently says they vendor the tool harness.
Not urgent — the three services already work; this is bringing their vendored docs in line with reality, not a behavior change.
Follow-up to my-things-core#57 (my-things-core PR #126), which declares the service archetype (
src/mythings/service-harness.md) but deliberately stops there — it's the "confirm before building" decision, not the retrofit itself.What's left
my-service-templaterepo (parallel tomy-template) vendoringSERVICE_HARNESS.mdinstead ofHARNESS.md, per service-harness.md's "per-service seams" section.my-server,my-telegram-bot, andmy-dashboard(its serving mode) to vendorSERVICE_HARNESS.mdinstead of the toolHARNESS.md, since their actual invariants (long-running, not issue-triggered, health surface, may not open a PR) now have a canonical home that matches what they actually are.Not urgent — the three services already work; this is bringing their vendored docs in line with reality, not a behavior change.