Planned reference runs

Commissioned, post-by-post, not yet written. This file exists because a 98-post plan held in a session dies with the container, which BACKLOG.md records having happened once already.

Three runs totalling 81 posts were in flight when this was written (2030-09-19 to 2032-04-22 in the Thursday queue). Everything below follows them, so the first slot here is 2032-04-29.

Scheduling consequence, stated once

The Thursday queue carries one post a week, shared between Under the Hood, Consulting and Craft, The Workshop and High Performance Teams. The 81 posts in flight plus the 98 below are 179 posts, which at one a week runs the Thursday queue from 2030-09-19 to 2034-03-23.

That is the arithmetic, not an objection. Two ways to shorten it if the runway becomes a problem, both of which are a decision rather than a detail:

• A second Thursday slot at 20:25. The mechanism exists: exam days already run two posts, and tech implementation tails already use that slot. Doubling Thursday halves the runway. It changes a documented cadence, so it is /publication-review/ and CLAUDE.md work as well as a reschedule.
• A separate weekday. Sunday is Cooking and the rest are taken, so this means displacing something.

Neither is assumed here. Everything below is laid one a week.

Run 4: the remaining Under the Hood suggestions (18 posts)

Four new groups, each verified absent from the corpus before being proposed. Group pages are created by hand before the run, never by the agents writing the posts.

Group	Posts	Slots
Air	4	2032-04-29 to 2032-05-20
The Archive	4	2032-05-27 to 2032-06-17
Trades	4	2032-06-24 to 2032-07-15
Assessment (second block)	3	2032-07-22 to 2032-08-05
Elections	3	2032-08-12 to 2032-08-26

Air. How a weather balloon works and why the upper atmosphere is measured by throwing something away. What an air quality monitor actually measures and why the particulate fractions are defined by size. How a tropical cyclone is forecast, and how the naming and category systems work. How refrigeration moves heat the wrong way up a gradient.

The Archive. How a library decides where a book goes, and classification as a lossy projection of a multidimensional subject onto a shelf. What a records retention schedule is for, and why destroying records on time is a legal act rather than negligence. How a museum decides what to keep, and accession as an irreversible commitment. Digital preservation and format obsolescence, where the medium outlives the reader.

Trades. How a house is wired, and why the rules are the shape they are: the earth path, the protective device, and what an RCD detects that a fuse cannot. How plumbing stops sewer gas coming back up, which is the trap and the vent and nothing else. How a slab is poured, cured and reinforced, and what goes wrong underneath it. What a building inspection actually checks, and what it explicitly does not.

Assessment, second block. How a driving test is standardised across assessors. How a trade licence is assessed when the thing being assessed is a physical skill. How university marks are scaled and moderated, and why a raw mark is almost never the reported mark.

Elections, beyond counting. How Does a Vote Get Counted? already exists and covers preferential and Senate counting. Not covered: how an electoral roll is maintained and why enrolment is the hardest data problem in the exercise; how a boundary redistribution is actually run; how pre-poll, postal and declaration votes are reconciled against the roll without anybody voting twice.

Run 5: Data Structures, in Go (22 posts)

New Under the Hood group, Data Structures, at /writing/data-structures/.

Every post answers the same six questions, in this order, which is the commission: what the structure is, what it costs (time and space, and the constant factors Go actually imposes), when to reach for it, when not to and what to use instead, how to implement it in Go, and how to test it. The testing section is the one that usually gets skipped and is the reason to write the series: a property-based test over a reference implementation finds more than any number of hand-written cases.

These are not -in-go tail posts. That suffix is reserved for posts pegged to a parent that publish the day after it in the 20:25 slot; these are standalone and take ordinary Thursday slots.

Go-specific content is the point of difference. Slices are not arrays, append aliasing is the most common real bug, map iteration order is deliberately randomised, container/list and container/heap exist and are mostly the wrong choice, generics changed what is writable, and escape analysis decides whether a node allocation is free.

1. Arrays and slices, and what append actually does
2. The dynamic array, and why amortised growth is not a trick
3. The singly linked list, and when a pointer chase is worth it
4. The doubly linked list, and why container/list disappoints
5. The stack
6. The queue
7. The ring buffer
8. The deque
9. The hash map, and how Go’s map actually works
10. The set, and why Go makes you build it
11. The binary search tree
12. Self-balancing trees, and the cost of keeping a promise
13. The B-tree, and why disks changed the shape
14. The binary heap and the priority queue
15. The trie
16. Graphs: adjacency list against adjacency matrix
17. Union-find, and the two tricks that make it almost free
18. The Bloom filter, and being wrong on purpose
19. The skip list, and probability instead of balancing
20. The LRU cache, and composing two structures
21. Fenwick and segment trees, for ranges
22. Persistent structures, and sharing instead of copying

Run 6: Patterns, the Gang of Four (24 posts)

New Under the Hood group, Patterns, at /writing/patterns/.

Post 1 is an introduction and it is what makes this series worth writing: what a design pattern is, that the catalogue is a description of what C++ and Smalltalk programmers kept building in 1994 rather than a prescription, and the honest critique. Several GoF patterns are workarounds for the absence of a language feature. A first-class function dissolves Strategy and Command. Go’s implicit interfaces dissolve much of Adapter. Iterator is a range loop. The series says so in post 1 and then treats each pattern as a named solution to a real recurring problem, with the honest note on whether it is still earning its place.

Creational: Abstract Factory, Builder, Factory Method, Prototype, Singleton. Structural: Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy. Behavioural: Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method, Visitor.

Each post: the problem it solves, the structure, a worked implementation, what it costs in indirection, when it is the wrong answer, and what a modern language gives you instead.

Run 7: Integration, the Enterprise Integration Patterns (30 posts)

New Under the Hood group, Integration, at /writing/integration/.

Hohpe and Woolf catalogue 65 patterns. Thirty are planned here: the integration-styles decision plus the patterns that recur in real systems. The remainder are mostly variants and narrow cases, and the run can be extended if the first thirty prove worth it.

Styles and channels (6). Choosing an integration style: file transfer, shared database, remote procedure invocation, messaging. Point-to-point channel. Publish-subscribe channel. Dead letter channel. Guaranteed delivery. Invalid message channel.

Message construction (4). Command, document and event messages, and why the distinction decides the coupling. Request-reply. Correlation identifier. Message expiration.

Routing (8). Content-based router. Message filter. Recipient list. Splitter. Aggregator. Resequencer. Scatter-gather. Process manager, and why a routing slip stops being enough.

Transformation (4). Message translator. Envelope wrapper. Content enricher and content filter. Claim check.

Endpoints (6). Polling against event-driven consumers. Competing consumers. Idempotent receiver, which is the one everybody needs and few build. Transactional client. Messaging gateway. Service activator.

Management (2). Wire tap. Control bus and the message store.

Run 8: Hexagonal architecture (4 posts)

Lands in the Patterns group rather than its own, since four posts do not carry a group page.

1. Ports and adapters, and what the hexagon is actually separating
2. What goes inside the hexagon, which is the only hard question
3. Testing at the boundary, and the test double that earns its place
4. Hexagonal in Go, where implicit interfaces change the ergonomics

Rules every run above inherits

From the three runs in flight, because they were learned the expensive way:

1. One agent, one new file. No agent touches _data/series.yml, any writing/**/index.html, any script, CLAUDE.md, or another post. All group pages are created by hand before the run.
2. Slots are verified disjoint before launch: no date overlap and no slug overlap against every other run and against what is on disk, and every slot confirmed a Thursday.
3. The title comes from the slug. The three runs in flight were specified with a positional maker, (date, slug, title, teach, intro), and the topic description went into the title slot on every non-Workshop post. Put the title in the title slot, or derive it from the slug with scratchpad/fix-titles.py, which is idempotent because a check-pass agent that rewrites a file restores the bad title.
4. Write then check, as a pipeline rather than two phases, so a post is checked as soon as it is drafted. The check pass is where the bullets-instead-of-paragraphs fault and the factual overreach get caught.
5. Reading times are stamped once for the whole set at the end, with make reading-times, never per post. Tell the check-pass agents to leave an existing reading_time alone, which the three runs in flight did not: their brief says only that a post must not carry one, so a reviewer rewriting a post after the whole-set stamp strips it, correctly by its own instructions. It recurred six times across run 2’s tail. The repair is python3 scripts/run-status.py --fix, but the brief is the place to fix it.