Concepts guide: skeleton

Source: Rufus's raw dictation, 15 Oct 2026. Target: guides/concepts.md (draft first at guides/drafts/concepts.md). Method as for the Beads guide: skeleton, critique, draft page, critique, Rufus review.

Audience and stance

• Reader: any team member, not a developer. Read this first, before How we use AI, Beads and setup.
• One message: our work is organised like an office. Post-its and documents; rooms with filing cabinets and corkboards; a management office that keeps pointers, not copies. A git repo is a filing cabinet.
• Short: about 900 words plus diagrams. One running example: the podcast.
• The metaphor is a way in, not the rules. Say once that it is rough; link the real rules (data model, workflow) rather than repeating them.
• Doesn't repeat How we use AI's interface/storage picture; links to it as "the next step".

Skeleton

Title and opening (~6 lines + Diagram 0)

• Title: "Concepts: post-its, filing cabinets and rooms".

• TL;DR, 4 lines: two kinds of material (post-its = tasks, documents = reference); work is grouped into rooms (initiatives) each with a filing cabinet and a corkboard; management keeps pointers, not copies; a git repo is a filing cabinet you can copy to your laptop and keep in sync.

• Ask: nothing; read it once so the other guides make sense.

• Diagram 0, the whole office (the one picture to remember):

  ┌──────────── Life Itself ─────────────────────────────────────────┐
  │                                                                  │
  │  ┌─ Management office ─┐   ┌─ Media House ────────────────────┐  │
  │  │ ▤ cabinet: planning │   │ ▤ cabinet   ▦ board              │  │
  │  │   └ pointer: ───────┼─┐ │  ┌─ Podcast (room in a room) ──┐ │  │
  │  │     "Podcast autumn │ └─┼─▶│ ▤ cabinet   ▦ board         │ │  │
  │  │      series → here" │   │  └─────────────────────────────┘ │  │
  │  └─────────────────────┘   └──────────────────────────────────┘  │
  │                            ┌─ Operations ─────────────────────┐  │
  │                            │ ▤ cabinet   ▦ board              │  │
  │                            └──────────────────────────────────┘  │
  └──────────────────────────────────────────────────────────────────┘
   ▤ filing cabinet = documents     ▦ corkboard = post-its (tasks)
  

1. Two kinds of material: post-its and documents (~6 bullets + Diagram A)

• Post-its are tasks: small, many, move around, get thrown away when done. "Book the guest", "Edit episode 3".

• They can stack: a big post-it (an epic) with smaller ones under it, and smaller ones under those. Each one stays small.

• Documents are reference: a plan, a guide, a contract, a description of a project and who leads it. Longer, change slowly, you keep them.

• Rule of thumb: if you'd tick it off, it's a post-it; if you'd look it up, it's a document.

• Why separate: post-its need to be seen and moved on a board; stuffed in a folder they get lost.

• Diagram A:

   Post-its (tasks)                       Documents (reference)
   on the corkboard                       in the filing cabinet
  
   ┌────────────────────┐                 ┌──────────────────┐
   │ Podcast autumn     │  epic           │ Podcast plan     │
   │ series             │                 │ ──────────────── │
   └─────────┬──────────┘                 │ Why we're doing  │
       ┌─────┴──────┐                     │ it, who leads,   │
   ┌───┴─────┐ ┌────┴────┐                │ what success     │
   │ Book    │ │ Edit    │  tasks         │ looks like ...   │
   │ guests  │ │ ep. 1   │                │                  │
   └───┬─────┘ └─────────┘                └──────────────────┘
   ┌───┴─────┐
   │ Email   │  sub-task                  Long, slow to change,
   │ Ana     │                            you look it up.
   └─────────┘
   Small, many, move, get ticked off.
  

2. Rooms, filing cabinets and folders (~6 bullets + Diagram B)

• Rooms are our departments: initiatives such as Media House or Operations. Rooms can sit inside rooms (Podcast inside Media House). Exactly how they nest is still being worked out; see the portfolio.

• Each room has a filing cabinet for its documents and a corkboard for its post-its.

• Each project gets a folder in the cabinet: the plan, its purpose, who leads it, anything else you'd need.

• The folder also says where its post-its are ("top left of the board"), because the post-its don't go in the folder.

• You can always add levels: a busy room might need three cabinets, one per podcast. Fine; the basic shape stays.

• Diagram B, one room close up:

   ┌─ Podcast room ─────────────────────────────────────────────┐
   │                                                            │
   │  ▤ Filing cabinet                 ▦ Corkboard              │
   │  ├─ 📁 Autumn series              ┌──────────┐             │
   │  │    ├ plan                      │ Autumn   │◀─┐          │
   │  │    ├ who leads, purpose        │ series   │  │          │
   │  │    └ "post-its: top left" ─────┼──────────┼──┘          │
   │  ├─ 📁 Guest list                 │ ▫ ▫ ▫    │             │
   │  └─ 📁 Show format                └──────────┘             │
   └────────────────────────────────────────────────────────────┘
  

  (Drop the emoji in the draft if it renders badly.)

3. Where do the cabinets go? Pointers, not copies (~5 bullets + Diagram C)

• Management wants to see every project. Option 1: all cabinets in the management office. Then the podcast team walks across the building every time they need a paper. Annoying.

• Option 2: each office keeps a copy. Copies drift: Rufus updates one, the podcast lead updates the other, and now they disagree.

• Our answer: the cabinet lives in the room where the work happens. The management office keeps a pointer: one sheet saying "Podcast autumn series exists; everything about it is in the podcast room."

• A pointer holds no content, only that something exists and where to find it. Same trick for post-its (a pointer post-it on the management board).

• Diagram C, three options:

   1. All in one office        2. Copies everywhere       3. Pointers (ours)
  
   Mgmt        Podcast         Mgmt        Podcast        Mgmt        Podcast
   ┌──────┐    ┌──────┐        ┌──────┐    ┌──────┐       ┌──────┐    ┌──────┐
   │ ▤ ▤  │◀───│      │        │ ▤    │    │ ▤    │       │ ↗    │───▶│ ▤    │
   │ ▤ ▤  │walk│      │        │ v1   │ ≠  │ v2   │       │ptr   │    │      │
   └──────┘    └──────┘        └──────┘    └──────┘       └──────┘    └──────┘
   long walks                  out of sync                one copy, findable
  

4. The digital version (table + Diagram D)

• The office is virtual. Same shapes, in Drive or on disk or in git.

• Mapping table:

  In the office	For us
  Room	An initiative or area (Media House, Podcast, Operations)
  Filing cabinet	A git repository (repo) on GitHub, or a Drive folder
  Project folder	A project's folder or file inside the repo, or a project Google Doc
  Document	Usually a Markdown file; sometimes a Google Doc
  Post-it	A task: in Beads, GitHub issues or Asana
  Corkboard	The task tracker for that repo
  Management office	The planning repo: its initiatives/ and projects/ folders
  Pointer	A record in planning that links to where the project really lives

• Inside a cabinet you can nest folders as deep as you like; the metaphor is crude on purpose.

• On your laptop: the life-itself folder holds the repos you've cloned, one per cabinet.

• Diagram D, on your disk:

   ~/src/life-itself/              ← your desk: the cabinets you've brought over
   ├── planning/                   ← management office cabinet
   │   ├── initiatives/
   │   └── projects/               ← project records, some are pointers
   ├── podcast/                    ← podcast cabinet
   │   ├── ...project folders...
   │   └── .beads/                 ← its corkboard
   └── content/
  

  (Check real repo layout before drafting.)

• When a cabinet gets too full, split it: Media House started with one repo; the podcast got its own. Reason: hard to find things, for you and for the AI; and one huge corkboard is bewildering.

5. Why a git repo makes a good filing cabinet (~5 bullets + Diagram E)

• A repo is a folder of files with superpowers. You can put anything in it; text files (like Markdown) work best.

• Clone = copy the whole cabinet to your laptop. Push and pull keep your copy and GitHub's in sync, so several people can work on the same cabinet.

• History: every change is saved, with who made it and when. You can go back in time.

• Changes go in as bundles (commits): rename a file and fix every link to it, all as one change. History never shows a half-broken state.

• What we want from any filing system: versions, easy sync, who did what. A nice screen used to matter most (why we liked Google Docs); with AI as the interface it matters less. See How we use AI.

• Diagram E:

     GitHub (shared copy)
     ┌──────────────┐
     │ ▤ podcast    │
     └──┬────────▲──┘
   clone│        │push
   /pull▼        │
     ┌──────────────┐        history (commits)
     │ ▤ podcast    │        ●──────●──────●──────● now
     │ your laptop  │        Ana    Rufus  Ana     you
     └──────────────┘        plan   rename+fix links
  

6. Where next (3 links)

• How we use AI: the AI as your interface to the office.
• Beads: the corkboard your AI uses.
• Getting set up: get the cabinets onto your laptop.

Open points for critique

• Title: "Concepts" is plain; alternatives "The office: how our work is organised", "Post-its and filing cabinets".
• Is section 5 (git) too much for a concepts guide, or exactly what's needed to make "clone a repo" make sense?
• Should the mapping table come before the metaphor (answer first), or after (story first)?
• Guide ordering: Rufus wants the guides ordered; this one would be number 1. Handle separately (index page).

Critique applied (v1 → draft)

Subagent critique, 15 Oct. Applied in the draft rather than re-editing the sketches above:

• Podcast tasks live in Asana, not the podcast repo's Beads; diagrams and table say so. The real pointer for the autumn series is pointer epic lip-a7l, a pointer post-it.
• Corkboard row: "wherever that room's tasks live", not "the repo's tracker". Pointer row: a short card (what, who, where), not an empty file. Management office named as the portfolio.
• Laptop path is ~/code/life-itself/ (as in the setup guide). Media House splitting a repo is stated as hypothetical.
• Whole-office diagram moved to the end of section 3 as a recap; symbols and emoji replaced with words; git diagram split into sync and history.
• Added: with Beads the board travels inside the cabinet. Title: "Post-its and filing cabinets: how our work is organised". Story first, table second. Guide ordering handled separately (index sorts by title).

v2 additions: skeleton (from dictation part 3)

Source: dictation part 3. Bead lip-d4l.8. Published in guides/concepts.md (v2) after Rufus's review.

Two new sections after "Why a git repo makes a good filing cabinet", plus one TL;DR sentence. Target: ~300 words added, two diagrams.

• TL;DR addition: work wherever suits you while creating; file checkpoints in the cabinet, because that's where people and the AI look.

6. The drafting table and the filing cabinet (~4 bullets + Diagram F)

• Writing a contract or a plan together: Sharpies, paper all over the table, sketching, talking. Use whatever helps you create: Google Docs is great for real-time collaboration.

• When there's a result, even an unfinished one, file a checkpoint in the cabinet. For us that means Markdown in git. What matters is the difference between creating and filing, not which tool.

• Papers can go back and forth: Rufus and Rosie's white paper: draft committed as Markdown, back to Google Docs to work on together, back into Markdown. Not a prescribed flow.

• You can ask the AI to do the filing: "Turn this into Markdown and put it in the planning repo, in projects/."

• Diagram F:

   Drafting table                         Filing cabinet
   whatever helps you create              Markdown in git
   (Google Docs, paper, a call)
  
   ┌──────────────────────┐   file a checkpoint   ┌──────────────┐
   │ messy, shared,       │ ────────────────────▶ │ draft 1      │
   │ live editing         │                       │ draft 2      │
   │                      │ ◀──────────────────── │ final        │
   └──────────────────────┘   take it out again   └──────────────┘
  

7. Why the AI needs the cabinet (~5 bullets + Diagram G)

• Two reasons to file checkpoints: people know where to look, and so does the AI. "I've got that half-finished draft" is only useful if the AI can find it.

• An AI session starts clean, as if there were no yesterday. (Memory features help a little.) All it knows is what it can read.

• So start a session in a repo, not your whole disk: it opens the right cabinet and knows where to look.

• Each repo has an AGENTS.md file: a README for the AI, read when the session starts. It says how the cabinet is organised: projects in projects/, initiatives in initiatives/. You rarely need to read it; we update it so the AI keeps finding things.

• It also points to the recipe books on the wall: skills (recipes for making a plan, adding tasks) and filing rules (where a project's owner and due date go, in the data model).

• Diagram G:

   New AI session: knows nothing
          │  you open it in a repo
          ▼
   ┌─ planning (a filing cabinet) ─────────────────────┐
   │ AGENTS.md     read first: how this cabinet works  │
   │ skills/       recipes: make a plan, add tasks     │
   │ docs/         filing rules: owner, due date ...   │
   │ projects/     initiatives/     ...                │
   └───────────────────────────────────────────────────┘
  

Open points

• Placement: new sections at the end (after git), or "drafting table" next to "Post-its and documents"?
• Metaphor for AGENTS.md: "instructions taped inside the cabinet door" vs Rufus's "README for AI". Recipes = skills fits his "recipe books on the wall".
• Does the title still fit, or add "and how the AI finds things"?