@connextar/house 0.15.0 → 0.15.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +12 -1
- package/docs/RoutineOperations.md +140 -0
- package/docs/templates/RoutineOperations.md +43 -0
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -584,6 +584,14 @@ runbook — is [`docs/ReleaseProcess.md`](docs/ReleaseProcess.md), shipped in th
|
|
|
584
584
|
package. Each app's own `docs/operations/ReleaseProcess.md` links to it and adds
|
|
585
585
|
only what is its own: its public API, its trigger documents, its history note.
|
|
586
586
|
|
|
587
|
+
Beside it, [`docs/RoutineOperations.md`](docs/RoutineOperations.md) is the method
|
|
588
|
+
for the recurring checks that keep an app ready, aligned and compliant — security
|
|
589
|
+
rounds, release gates, bills, backups, the privacy policy against the code — each
|
|
590
|
+
with when it last ran and when it's next due. An app copies
|
|
591
|
+
[`docs/templates/RoutineOperations.md`](docs/templates/RoutineOperations.md) to its
|
|
592
|
+
own `docs/operations/RoutineOperations.md`, which holds only its register and run
|
|
593
|
+
log, and its `AGENTS.md` tells every agent to read the Next due column first.
|
|
594
|
+
|
|
587
595
|
### `@connextar/house/changelog`
|
|
588
596
|
|
|
589
597
|
`<Changelog releases={CHANGELOG} />` — the body of a `/changelog` page. Each
|
|
@@ -2079,7 +2087,10 @@ Then, per module the app takes up:
|
|
|
2079
2087
|
§7: the old entries become numbered releases once, `lib/release.test.ts` guards
|
|
2080
2088
|
them from then on, and the app's own `docs/operations/ReleaseProcess.md` says
|
|
2081
2089
|
only what is its own.
|
|
2082
|
-
5. **
|
|
2090
|
+
5. **Routine operations** follow [`docs/RoutineOperations.md`](docs/RoutineOperations.md):
|
|
2091
|
+
copy the template to `docs/operations/RoutineOperations.md`, fill the register
|
|
2092
|
+
from its §5, and add its §6 pointer to `AGENTS.md`.
|
|
2093
|
+
6. **Gates, then the pages.** `npm run check`, `npm test`, `npm run build`, and
|
|
2083
2094
|
grep the built CSS for a class that only the package uses — the one check that
|
|
2084
2095
|
proves step 1.
|
|
2085
2096
|
|
|
@@ -0,0 +1,140 @@
|
|
|
1
|
+
# Routine Operations
|
|
2
|
+
|
|
3
|
+
> The method every Connextar app uses to keep its recurring checks in one place: what each one is for, how often it runs, how to run it, when it last ran and what it found, and when it's next due. Scheduled checks get lost in day-to-day work; a register that every task starts by reading is what stops that. Shared by the cohort and shipped inside `@connextar/house`, beside [ReleaseProcess.md](ReleaseProcess.md); each app keeps a `docs/operations/RoutineOperations.md` that holds its own register and run log.
|
|
4
|
+
|
|
5
|
+
_First written for AltEd on 2026-10-16 (its v0.116.0) and generalised for the cohort the same day._
|
|
6
|
+
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
## 0. What each app's own document says
|
|
10
|
+
|
|
11
|
+
This document is the method. An app's `docs/operations/RoutineOperations.md` links here and holds three things nobody else can write:
|
|
12
|
+
|
|
13
|
+
1. **Its register** — one row for every routine the app has (§2), manual and automated.
|
|
14
|
+
2. **Its run log** — one line for every run (§3, step 5), newest first.
|
|
15
|
+
3. **Its standing go-aheads** — any routine the owner has said may read or write production without asking each time, recorded on that routine's row.
|
|
16
|
+
|
|
17
|
+
Start it from [templates/RoutineOperations.md](templates/RoutineOperations.md): copy it to `docs/operations/RoutineOperations.md`, put the app's name in the title, and fill the register (§5 lists the rows most apps start with). Then add the pointer in §6 to the app's `AGENTS.md`.
|
|
18
|
+
|
|
19
|
+
The method is not copied into the app. If it needs to change, change it here, so every app changes with it.
|
|
20
|
+
|
|
21
|
+
---
|
|
22
|
+
|
|
23
|
+
## 1. What a routine is
|
|
24
|
+
|
|
25
|
+
A **routine** is any check or chore that has to happen again and again, on a calendar or on a trigger, whether or not anything is broken. It belongs on the register if forgetting it would cost something: a security gap, a wrong price, a bill, a broken promise in the privacy policy, a stale document.
|
|
26
|
+
|
|
27
|
+
There are two kinds:
|
|
28
|
+
|
|
29
|
+
- **Manual:** a person or an agent runs it and records the result. Security rounds, a pricing or usage baseline, the month's bill check.
|
|
30
|
+
- **Automated:** the app runs it by itself on a schedule. Scheduled jobs and crons. The register still lists these, because someone has to look at whether they're running.
|
|
31
|
+
|
|
32
|
+
---
|
|
33
|
+
|
|
34
|
+
## 2. The register
|
|
35
|
+
|
|
36
|
+
Every routine has one row, with:
|
|
37
|
+
|
|
38
|
+
| Field | What it holds |
|
|
39
|
+
| ------------ | ----------------------------------------------------------------------------------------------------------- |
|
|
40
|
+
| **ID** | `OPS-nn`. Never reused, so the run log can point at it. |
|
|
41
|
+
| **Routine** | Its name, in plain words. |
|
|
42
|
+
| **Why** | What goes wrong if it's skipped. |
|
|
43
|
+
| **When** | A calendar cadence ("monthly, mid-month") or a trigger ("after every 5 feature tranches", "every release"). |
|
|
44
|
+
| **How** | The command or runbook, and anything it must never do (for example, write to production). |
|
|
45
|
+
| **Record** | Where the full result goes: a document, a dashboard. |
|
|
46
|
+
| **Last run** | Date, version and a one-line result, or "Not recorded". |
|
|
47
|
+
| **Next due** | A date, or the trigger that makes it due. |
|
|
48
|
+
| **Status** | One of the keys below. |
|
|
49
|
+
|
|
50
|
+
### Status keys
|
|
51
|
+
|
|
52
|
+
| Status | Meaning |
|
|
53
|
+
| -------------- | --------------------------------------------------------------- |
|
|
54
|
+
| ✅ On schedule | Ran when due; next run not yet due. |
|
|
55
|
+
| 🟨 Due | Due now, or due by the next release. |
|
|
56
|
+
| 🟥 Overdue | Past its date or trigger and not run. |
|
|
57
|
+
| ⏰ Scheduled | A run is booked, for example a scheduled task (§4). |
|
|
58
|
+
| 🤖 Automated | The app runs it itself; the row is about watching it. |
|
|
59
|
+
| ⚪ Proposed | Suggested, not yet agreed by the owner. Not counted as overdue. |
|
|
60
|
+
| 🧊 Paused | Deliberately off, with the date and reason recorded. |
|
|
61
|
+
|
|
62
|
+
### How the register is laid out
|
|
63
|
+
|
|
64
|
+
- **Manual routines** — the full table, every field above.
|
|
65
|
+
- **Automated routines** — a shorter table (ID, job, what it does, when, status), headed by a sentence saying where to watch them: the app's job-health page, its operational summary email, its host's cron dashboard. Say how often to look (at least weekly) and when to look sooner.
|
|
66
|
+
- **Paused** — ID, routine, why paused, since.
|
|
67
|
+
|
|
68
|
+
---
|
|
69
|
+
|
|
70
|
+
## 3. Running a routine
|
|
71
|
+
|
|
72
|
+
1. **Check it's due.** At the start of any piece of work, read the register's **Next due** column. A 🟨 Due or 🟥 Overdue routine runs before new feature work, or the owner says why not.
|
|
73
|
+
2. **Run it exactly as its How column says.** If the How has gone stale, fix the How first.
|
|
74
|
+
3. **Never write to production as part of a routine** unless its How says so and the owner has said yes for this run. Reads against production need the owner's go-ahead too, unless the row records a standing one.
|
|
75
|
+
4. **Record the full result where its Record column says.**
|
|
76
|
+
5. **Add a line to the run log:** date, ID, who ran it, the result in a sentence, and any follow-up.
|
|
77
|
+
6. **Update the row:** Last run, Next due, Status.
|
|
78
|
+
7. **Act on findings** by the rules of the routine's own record. For a security round: Critical and High get fixed before anything else.
|
|
79
|
+
8. **Release if a status document changed**, following [ReleaseProcess.md](ReleaseProcess.md).
|
|
80
|
+
|
|
81
|
+
---
|
|
82
|
+
|
|
83
|
+
## 4. Adding, changing, retiring and booking
|
|
84
|
+
|
|
85
|
+
### Adding or changing a routine
|
|
86
|
+
|
|
87
|
+
- Add a row with the next free ID. A new routine starts ⚪ Proposed until the owner agrees its cadence.
|
|
88
|
+
- When something new needs regular attention (a new paid service, a new scheduled job, a new legal promise), add it to the register **in the same change set that creates it**.
|
|
89
|
+
- A change to a routine's cadence or How is a change to its row, with a run-log line if it follows from a run.
|
|
90
|
+
|
|
91
|
+
### Retiring a routine
|
|
92
|
+
|
|
93
|
+
Set it to 🧊 Paused and move it to the Paused table, with the date and the reason. Don't delete it: the run log still points at it, and IDs are never reused.
|
|
94
|
+
|
|
95
|
+
### Booking runs
|
|
96
|
+
|
|
97
|
+
A routine with a calendar cadence should have its next run booked, not just remembered. Book it as a scheduled task in Claude, or as a calendar reminder for a person, name the booking on the row's **Next due** ("2026-11-15 09:00, scheduled task `app-pricing-baseline`"), and set the row to ⏰ Scheduled.
|
|
98
|
+
|
|
99
|
+
Whatever runs it follows this document: record, log, update the row. A booked run that touches production says so in its own instructions, and leaves its result uncommitted for review.
|
|
100
|
+
|
|
101
|
+
---
|
|
102
|
+
|
|
103
|
+
## 5. Rows most apps start with
|
|
104
|
+
|
|
105
|
+
Copy the ones that apply into the new register, as ⚪ Proposed until the owner agrees each cadence, and make each How the app's real command. One that doesn't apply yet (no payments, no AI) is left out; one that applies but is off for now goes in the Paused table with the reason.
|
|
106
|
+
|
|
107
|
+
| Routine | Typical When | Typical How |
|
|
108
|
+
| ---------------------------------------- | ------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------- |
|
|
109
|
+
| Security and QA audit round | After every 5 feature tranches (the delivery workflow's cadence). | The delivery workflow's audit round: the full test suite, typecheck and lint, the build, `npm audit --audit-level=moderate`. |
|
|
110
|
+
| Documentation pruning round | After every 10 feature iterations. | Dedupe and restructure the status documents; never drop open work. |
|
|
111
|
+
| Release gates | Every release. | The app's check, test, build and release-guard commands, each read by its exit status ([ReleaseProcess.md](ReleaseProcess.md)). |
|
|
112
|
+
| Browser sweep, including phone width | With each security round, and with any change to shared layout. | The app's end-to-end and accessibility suites. |
|
|
113
|
+
| Privacy policy against what the app does | With each security round, and with any change to analytics, email or AI. | Read the policy's promises against the code: what's recorded, where, for how long, by which providers. |
|
|
114
|
+
| Hosting, database and provider bills | Monthly, when the invoices arrive. | Compare with last month; explain any jump before it compounds. |
|
|
115
|
+
| AI and third-party prices | Monthly, if the app prices anything from a provider's cost. | Compare the app's stored prices and exchange rates with the providers' published ones; change them only with the owner. |
|
|
116
|
+
| Payments, end to end | After any change to checkout or webhooks, and once a quarter. | One real purchase of each kind, then a refund; check every record and message the customer should get. |
|
|
117
|
+
| Backups and a restore drill | Quarterly. | Restore into a branch or a scratch database and check it opens. A backup nobody has restored is a hope, not a backup. |
|
|
118
|
+
| Dependency and shared-package currency | Monthly, or when `@connextar/house` releases. | `npm outdated`; take up the house package's new version by its README; note anything held back and why. |
|
|
119
|
+
| Watching the scheduled jobs | Weekly (automated rows). | The app's job-health page or summary email: every job ran, none is failing, none is running far more often than it should. |
|
|
120
|
+
|
|
121
|
+
If continuous integration is switched off, add it to the Paused table with the reason, and make the release gates and the browser sweep the routines that stand in for it.
|
|
122
|
+
|
|
123
|
+
---
|
|
124
|
+
|
|
125
|
+
## 6. The pointer in `AGENTS.md`
|
|
126
|
+
|
|
127
|
+
Add this section to the app's `AGENTS.md`, so every agent reads the register before it starts:
|
|
128
|
+
|
|
129
|
+
```markdown
|
|
130
|
+
## Routine operations
|
|
131
|
+
|
|
132
|
+
- **`docs/operations/RoutineOperations.md` is the register of recurring checks**,
|
|
133
|
+
with when each last ran and when it's next due. At the start of a task, read its
|
|
134
|
+
**Next due** column: a routine that is due or overdue runs before new feature
|
|
135
|
+
work, or the owner says why not.
|
|
136
|
+
- After running one, record it as the shared method says
|
|
137
|
+
(https://github.com/Connextar/cx-house/blob/main/docs/RoutineOperations.md):
|
|
138
|
+
the full result in its record, a line in the run log, and the row's Last run / Next due / Status.
|
|
139
|
+
Add a row in the same change set as anything new that needs regular attention.
|
|
140
|
+
```
|
|
@@ -0,0 +1,43 @@
|
|
|
1
|
+
# App name — Routine Operations
|
|
2
|
+
|
|
3
|
+
> The recurring checks that keep App name ready, aligned and compliant: what each one is for, how often it runs, how to run it, when it last ran and what it found, and when it's next due. The method — the fields, the status keys, how to run, add, retire and book a routine — is the cohort's, in `@connextar/house`: [`docs/RoutineOperations.md`](https://github.com/Connextar/cx-house/blob/main/docs/RoutineOperations.md). This file holds only App name's register and run log. Sits beside [ReleaseProcess.md](ReleaseProcess.md); [`AGENTS.md`](../../AGENTS.md) points here.
|
|
4
|
+
|
|
5
|
+
_Last updated: YYYY-MM-DD — first version._
|
|
6
|
+
|
|
7
|
+
**At the start of a task, read the Next due column.** A 🟨 Due or 🟥 Overdue routine runs before new feature work, or the owner says why not.
|
|
8
|
+
|
|
9
|
+
Status keys: ✅ On schedule · 🟨 Due · 🟥 Overdue · ⏰ Scheduled · 🤖 Automated · ⚪ Proposed · 🧊 Paused.
|
|
10
|
+
|
|
11
|
+
---
|
|
12
|
+
|
|
13
|
+
## 1. Register
|
|
14
|
+
|
|
15
|
+
### 1.1 Manual routines
|
|
16
|
+
|
|
17
|
+
| ID | Routine | Why | When | How | Record | Last run | Next due | Status |
|
|
18
|
+
| ------ | ------- | --- | ---- | --- | ------ | -------- | -------- | ------ |
|
|
19
|
+
| OPS-01 | | | | | | | | |
|
|
20
|
+
|
|
21
|
+
### 1.2 Automated routines
|
|
22
|
+
|
|
23
|
+
The app runs these itself. The routine here is **watching** them: say where (a job-health page, a summary email, the host's cron dashboard), how often to look, and when to look sooner.
|
|
24
|
+
|
|
25
|
+
| ID | Job | What it does | When | Status |
|
|
26
|
+
| --- | --- | ------------ | ---- | ------ |
|
|
27
|
+
| | | | | |
|
|
28
|
+
|
|
29
|
+
### 1.3 Paused
|
|
30
|
+
|
|
31
|
+
| ID | Routine | Why paused | Since |
|
|
32
|
+
| --- | ------- | ---------- | ----- |
|
|
33
|
+
| | | | |
|
|
34
|
+
|
|
35
|
+
---
|
|
36
|
+
|
|
37
|
+
## 2. Run log
|
|
38
|
+
|
|
39
|
+
Newest first. One line a run: date · ID · who · result · follow-up.
|
|
40
|
+
|
|
41
|
+
| Date | ID | Who | Result | Follow-up |
|
|
42
|
+
| ---- | --- | --- | ------ | --------- |
|
|
43
|
+
| | | | | |
|