Fortnight recap — brief and plan

The fortnight recap is a single page that tells the Life Itself team what we got done in the last two weeks, whether we are on track, and what we need from them. This brief sets what it is for and what "good" means, using the first real run (8 October 2026) as evidence. The working procedure is docs/fortnight-recap.md; this file holds the reasoning, evidence and plan.

Situation, complication, question

• Situation. Work happens across many repos (planning, design, 2rbook, pdf-report-publishing, sor-community, comms, podcast, wayintoai and others), each with its own changelog. People in the team see only their part.
• Complication. No one has a shared view of what we achieved, and a list of activity is overwhelming and doesn't say whether we are on track. On 8 Oct the first recap took a whole session to assemble by hand, with several rounds of feedback.
• Question. What page, made how, lets everyone grasp the fortnight in under a minute, see progress against our priorities, and know what is asked of them, and can be produced by someone other than Rufus every two weeks?

Audience and use

• Who: the internal Life Itself team (currently Rufus, Sylvie, Uriel, Asdra, Fae, Petronella and close collaborators). No board or external audience for now; write candidly.
• When: opened at the start of the fortnightly team meeting, walked through in the "What's happened" slot (about 10–15 minutes), and read afterwards by anyone who missed it.
• Where: the planning site, briefings/YYYY-MM-DD-recap/, linked from that meeting's doc. Phones as well as laptops.

Jobs the page must do

1. Orient in 30 seconds: are we on track, and what is the headline?
2. Show progress against priorities, starting with the top roadmap priority, not just a list of activity.
3. Celebrate real results with real images, so the team sees and feels what shipped.
4. Ask: make clear the two or three things we need from people.
5. Route to depth: every item links to its source (a repo changelog, recap or the live thing) for anyone who wants detail.

Not its job

• The task queue (that is Beads) or the agenda and decisions (that is the meeting doc).
• The roadmap or what's next in detail (that is the roadmap page; the recap shows only the top priority's status).
• A complete record of everything that happened (that is the changelogs).

Success criteria

• The headline, TL;DR and priority strip fit on one laptop screen; the whole page is at most two screens on desktop.
• Someone reading only the top screen can say what the fortnight's story is and whether we are on track.
• At most five cards; every card is a result (something now exists or works), not a task or intention.
• Every card has a relevant image of the thing itself, and a link to more.
• Each ask is specific and owned.
• It can be produced in under an hour from changelogs by someone other than Rufus, with AI.

Evidence from the first run (8 October 2026)

• v1 (in git history: briefings/2026-10-08-recap-v1/ at commit 8d95bb7): about eight screens; theme sections repeating the cards; generic headline ("What we've been up to"); a paragraph intro. Rufus: "a bit overwhelming"; the opening paragraph "unreadable"; wanted a tighter TL;DR.
• Content feedback that generalises:
  • Get facts right about what's special: the Wisdom paper is our sixth white paper and the first in the Seeds of Renaissance brand, not our "first paper".
  • Leave out side projects that aren't core to Life Itself (Way Into AI Weekly was cut).
  • Use the most beautiful real image (the paper's promo art), not a screenshot of a web page; avoid images that distract or misrepresent (a YouTube thumbnail sheet for "calls, hiring and podcast").
  • Don't repeat the roadmap; keep "what's next" detail on the roadmap and meeting doc.
  • Don't duplicate the recap in the meeting doc: one source for "what happened".
  • Link to repo-level recaps where they exist (the design repo's own recap).
• Process lessons:
  • Aggregating from changelogs worked; repos with good entries and images (planning, design) were easy, repos without them were thin or invisible (ops, inbox reviews, community work).
  • Facts change during the day (the call moved from 15 to 22 Oct); the recap needs a quick final check against the meeting doc.
  • Keep earlier versions available while a page is in use (v1 kept and linked).
  • Plain-text diagrams in Markdown; Mermaid breaks on the planning site without MDX mode.
• v2 (in git history: briefings/2026-10-08-recap/ at commit 1328f85): answer-first headline, Shipped / Moving / Changing, launch-path strip, six outcome cards, an "Also shipped" line and asks. Evaluated below.

Evaluation of v2

Independent review on 8 Oct against this brief and information-design practice (pyramid principle, Tufte, Nielsen, WCAG), with desktop and mobile-emulated screenshots of the live page.

Verdict. A big step up from v1: the top screen tells the story and fits one laptop screen. Four problems:

• Phone: unreadable, because the page had no viewport tag.
• Repetition: the TL;DR and the cards say the same things.
• Priority strip: it isn't honest about status.
• Length: at about 2.7 screens, the page fails the two-screen criterion.

Factual drift found:

• "The brand is set" and "Rebrand: done" overclaim, since brand V1 is still this week's work.
• The website was marked "planned", but mockups exist, so it is in progress.
• The paper card should say "published; public launch 18 Nov".
• The strip drew a straight line where the roadmap has the website and rollout running in parallel.
• Headlines and status words drift into slogans unless each must cite evidence.

Rules adopted from the review

v3 (live) applies these rules: Done / At risk / Changed, a parallel priority strip with a next gate, four result cards, owned asks.

1. Each block has one job; no repetition.

   • Headline: the story.
   • TL;DR: on track? what's at risk? what changed? (Done / At risk / Changed.)
   • Priority strip: status.
   • Cards: evidence of results.
   • Asks: what we need.

   In-flight work goes in the strip or the asks, never in cards.

2. Claims cite evidence. "On track" or "done" must point to something that exists. The strip carries one mandatory "next gate / risk" line.

3. Fixed status vocabulary for the strip: done, in progress, planned, at risk, goal. Each has a distinct, legible style. Stages follow the roadmap's real dependencies.

4. Cards: at most five, results only. Use an outcome title, one line on why it matters, an image of the thing itself readable at card size (a crop is set per image), and a "More" link. No image means no card; the item goes in Also shipped.

5. Asks name an owner and a date.

6. Technical floor:

   • doctype, lang and viewport meta;
   • visible keyboard focus on every link;
   • text contrast AA in light and dark;
   • checked on a real phone or with true mobile emulation, not a narrow desktop window.

7. Final fact check against the meeting doc and roadmap on the day; facts move during the day.

8. Content separate from layout. A data file per fortnight drives one clean template (no leftover CSS). Editorial judgment is limited to the headline, the cut and the risk line; everything else is fixed.

Plan

1. Brief (this file): agree purpose, audience, success criteria. ← now
2. Evaluate v2 against the brief and information-design practice; fold the core findings into this brief and the procedure. ← done 8 Oct; page fixes below not yet applied except the viewport tag.
3. Template: separate content from layout (a small data file per fortnight: headline, TL;DR, priority stages, cards, also-shipped, asks) so a recap is made by filling data, not editing HTML.
4. At the source: add to the changelog convention a "why it matters" line and an image for promote: true entries.
5. Skill: a recap skill that gathers promoted entries across repos for the period, drafts the data file, and builds the page; a person writes the headline and makes the cut.
6. Run it for the next fortnight (around 22 October) with someone other than Rufus producing it, and review against the success criteria.

Page fixes (v2 → v3, applied after the meeting)

1. Rewrite the TL;DR as Done / At risk / Changed. Cut to five or fewer cards: merge "community and podcast" into Also shipped, and drop or recast "we plan in one place".
2. Strip: website as in progress (sign-off this week); a distinct planned style; a parallel shape matching the roadmap; a risk line under Launch. Soften "the brand is set" and "done".
3. Asks with owners: home page (Sylvie, Rufus, today); call roles (Petronella); comms hire task (owner to name).
4. Card links: a real link on the title with an overlay, so focus is visible. Better crops: PDF strip contain, the thing itself rather than screenshots.
5. Remove the leftover v1 CSS.

Open questions

• Fortnightly or weekly? (Fortnightly assumed; it matches the meeting rhythm we want.)
• Does the recap later go wider (community, funders), and if so as a separate, edited version?
• Who produces it from the next run: Asdra, Fae, or Uriel?