Sense 32: The Chores — The Pulse That Doesn't Beat Itself

Sense 32 · Steady · Last touched 2026-08-20

• last_verified: 2026-07-27

Synced from docs/design/sense_32_the_chores.md in the engine repo — that’s the source; this page is a build-time mirror.

Sense 21 named the automated pulse — make, publish, sync, pulse, reconcile.

But systems run themselves only as far as their chores are tended. Some pulses come from cron. Others come from a Sunday morning and a human who remembered.

Status: proposed Date: 2026-05-12 Author: the owner + Claude (afternoon, post-journal-publication)

---

What pulled us in

jinflow runs a lot of itself. just ci heartbeats every 15 minutes. jin make regenerates the KLS deterministically from the AFS. The release pipeline tags, generates notes, pushes. The Heartbeat (Sense 21) describes this automated pulse and names its phases.

But there is a second pulse, off-clock and unscheduled, that a single person presently carries:

• The weekly journal entry that captures what shipped and why.
• The monthly retrospective that pulls threads.
• The sweep of logs/ci/incidents/ so the directory doesn’t accumulate forever.
• The check that Fly is healthy and within budget.
• The re-sync of site/src/content/docs/journal/ when docs/journal/ was edited.
• The certificate that needs fly certs add before a new client lands.
• The terminology drift that has been quietly leaking into commit subjects and needs a _SANITIZE_PATTERNS entry.
• The releases.md regeneration after a history change.

None of these are bugs. None of them belong in jin make. They are human-cadenced upkeep — the chores that keep an automated system running.

Today they live in one place: memory. The author’s. When that memory drifts, the chore drifts. When the author hands the system to someone else, the chores don’t transfer.

Chores that live only in someone’s head are not really part of the system. They’re a private habit on top of one.

The Principle

Chores are first-class artifacts. They get:

• A name. “Write the weekly journal” is a chore. “Stay on top of stuff” is not.
• A cadence. Daily, weekly, monthly, per-release, on-event. On-event counts — “after CI flips red, read the DIAGNOSIS.md” is a chore with a known trigger.
• An owner role. Not a person — a role. “Estate operator” not “the owner”. So the chore survives rotation.
• A procedure. One sentence, or one command. If the procedure is long, the chore needs decomposing.
• A registry. A single file where they all live. Versioned with the code. Reviewable in PR.

The registry does not have to be enforced. It has to be visible. The act of naming a chore is most of the value — what gets named gets remembered; what gets remembered gets handed off.

The Taxonomy

Cadence	Examples
Continuous (automated)	just ci heartbeat. Not chores — listed for completeness.
Daily	Skim CI status if amber/red. Commit & push current branch. (Mostly already habitual.)
Weekly	Write the journal entry for the previous ISO week. Glance at Fly billing. Skim What’s New + Recents for drift.
Monthly	Write the monthly retrospective. Sweep logs/ci/incidents/ >30d. Review pinned issues, retire ripened TODOs. Verify certificate expiry runway.
Per-release	Mostly automated by just ship. Listed because regression hazards live here.
On-event	”After ___, do ___.” Named triggers, named actions. Example: after jin make rewrites a KLS, the dev JinDesk auto-reloads (this used to be a chore; the fix on 2026-05-11 retired it).

The taxonomy is not theoretical. Every chore that exists today fits cleanly into one of these rows. Chores that don’t fit are usually too vague — they need rewording, not a new bucket.

Relationship to Sense 21 (The Heartbeat)

Heartbeat names what the system does on a schedule. Chores names what the operator does on a schedule. They are two halves of the same pulse.

A useful test, when looking at an operational concern:

• If automating it is cheap and reliable, it belongs in the Heartbeat. Wire it.
• If it requires judgement, taste, or context the system can’t have, it belongs in the Chores. Register it.
• If you can’t tell, write the chore first, then automate it later. The registry entry is what makes the automation lossless.

Some chores graduate to Heartbeat (the dev-server reload moved from “remember to restart” to “auto-detected”). Some never will (the weekly journal entry has taste in it; the system can collect the commits, but the opinion is human).

The Registry

Lives at docs/operations/chores.md. Markdown, sectioned by cadence. One entry per chore: name, owner role, procedure, notes. Editable like any other docs file. Reviewable like any other PR.

Why markdown and not YAML / a database?

• The chores need to be readable, not queryable. A human glances at them.
• They evolve. A YAML schema would calcify; markdown encourages annotation.
• They don’t need machine consumption. If they ever do (e.g., a future Steward dashboard surfaces them), the markdown is the source of truth and can be parsed.

The registry is intentionally not a TODO list. TODOs are unfinished work. Chores are work that finishes and then comes back. Different shape.

What This Is Not

• Not a workflow engine. No automation, no triggers, no scheduling daemon. Those belong to the Heartbeat side.
• Not a backlog. Chores recur. Items that don’t recur belong in todo.md or an issue tracker.
• Not a discipline. It’s a list. Disciplines come from leaning on the list, not from the list itself.
• Not a public artifact (yet). Chores live in docs/operations/, the operator’s territory. They could surface in a Steward dashboard later — see Sense 24 — but the first home is humble.

Future Directions

Three obvious paths from here, each cheap:

1. just chores — print the registry, optionally filtered by cadence. Zero new infrastructure.
2. Heartbeat-side reminders — just ci could nag (e.g., notify on Monday morning if 2026-WNN.md doesn’t exist for last week). Cheap; gentle pressure.
3. Steward integration — when Sense 24 grows surfaces, the Chores registry feeds the “what’s overdue?” view. The Estate Map gains a row per chore, age-coloured.

None of these are required. The registry alone is the load-bearing idea.

How this manifests in jinflow

The Chores registry is the human-cadenced upkeep complement to Sense 21 — The Heartbeat (the system-cadenced one). The canonical list lives in docs/operations/chores.md; each chore names what it is, the cadence, and the responsible role. Daily / Weekly / Monthly / Per-Release / On-Event / Retired categories. Adding or retiring a chore is a git edit, not a config push.

• Registry: docs/operations/chores.md (single source of truth)
• Cadences: daily, weekly, monthly, per-release, on-event, retired (with date)
• Pairs with: Sense 21 — The Heartbeat (the machine-cadenced upkeep loop)

Status: shipped.

---

Open Questions

• Whose chores? A pack maintainer’s chores differ from an engine maintainer’s. Should the registry split by role, or stay flat and tag-per-entry? Lean: flat with tags, splits emerge if useful.
• How do chores die? A chore that’s been automated should leave a trace. Suggested: keep retired chores in a ## Retired section with a date, rather than deleting them — the retired chore says “this used to be your problem; now it isn’t.”
• Do chores have SLAs? A weekly journal entry could be a week late. A Fly billing check four months late starts to bite. Soft cadences vs. hard cadences may want different visual treatment. Defer.
• Cross-tenant chores in multi-tenant deploys? When the Steward (Sense 24) is real, some chores will need per-tenant tracking. The registry as written is single-instance. Defer with the Steward.

Status

Proposed. The registry at docs/operations/chores.md is the first concrete instance. Once it has been carried for a month or two, the shape of what needs to scale (or doesn’t) will be visible.

Until then: name the chores, write them down, do them on Sunday morning.

---

Numerical neighbors: ← Sense 31: The Inlet — Where Bytes Come From Is the Channel’s Business · Sense 33: The Bell — When the System Notices, the Person Hears →