Project-Management Infrastructure

Owner: Rufus · Parent: Life Itself Management · Tasks: Beads lip-tqk (bd list --parent=lip-tqk) · Analysis: LTP report

Summary

• What: a shared way to plan, track and report on work, so that everyone, human and AI, knows what to do next, where work is recorded, and trusts that information.
• Why now: more of our work runs through AI and the team is growing. Without shared routines AI adds to the mess, and today tasks are scattered across three tools, often duplicated and hard to check.
• Diagnosis: four likely root causes, from the LTP. (1) No agreed rule or system of record for where each kind of thing goes. (2) No planning owner or process, so priorities reach people ad hoc. (3) Two teams in two tools: operations in Beads and GitHub, Media House in Asana. (4) Building the system while running everything else.
• Plan: a trial of one system of record per kind of work, with crossover work linked rather than copied. A Monday team plan picks projects and each one's goal for the week, with priority kept on initiative records; project owners handle tasks with their team. Well-planned project records (objective, owner, an LTP when significant), backed by shared AI skills, then a guide and a briefing.
• Now: the trial runs from 19 Oct to 26 Nov, with the post-trial review on 3 Dec. All four trial decisions were made on 2 Nov (routing line, which repository's Beads, crossover rule, request inbox). Focus now: well-planned projects and the Monday team plan.
• Changed 2 Nov: clean projects, not clean tasks. The team plan prioritises projects and each one's next goal; project owners handle tasks with their team. The per-person task page, organisation-wide task sweeps, task-data clean-up, data steward, cross-tool task convention and Thursday slot were dropped.

Done when

Confirmed by Rufus on 22 Oct 2026. Each key result tests part of the goal tree below.

1. The routing line between Asana, Beads and GitHub (including which repository's Beads) is agreed, run on real work in the trial, and kept or fixed at the post-trial review; asked where they would log three example tasks, each team member gets them right.
2. A team plan is written weekly or fortnightly, with no gap, from now to the post-trial review (3 Dec), and every active initiative record carries its current priority.
3. Every active project on a ★★ or higher initiative is well planned: a clear objective and done_when, an owner, and an LTP or issue tree when it is significant. Its tasks are the project owner's to keep; there are no organisation-wide task sweeps. (Changed 2 Nov 2026 from a task-data test: Rufus, "clean projects, not clean tasks".)
4. Every active project has a minimal record (objective, decisions, open questions, status) that can be reached from the portfolio.
5. Each Monday plan, up to the post-trial review, shows every team member which projects are theirs and what each should achieve that week; AI answers about work link the source record; Sylvie and Valerie say the plan tells them what they need. (Changed 2 Nov 2026 from a per-person page drawn from Asana, Beads and GitHub: owners handle tasks with their team.)
6. The "How we plan and track work" guide is published, each team member has installed the shared planning skills, and the onboarding checklist has been used at least once.

Status

Where we are, 7 Nov 2026. ● done · ◉ built, waits on a person · ◐ underway · ○ not started.

GOAL: each person knows their projects
      and this week's goal

1 RULES ................... ● decided 2 Nov
  ● Asana line, repo rule, crossovers
  ● Trial 19 Oct–26 Nov, review 3 Dec
  ○ Request inbox file .... Rufus .65
        │
        ▼
2 CLEAN PROJECTS (branches)
  ● Initiative stars on records
  ● Weekly review flags project gaps
  ◐ Gaps 36 → ~21; done_when left .76.5
  ◉ Project-planning skill ... .29.4
        │
        ▼
3 MONDAY PLAN
  ◐ Week note every Monday ... .48
  ○ Asdra takes the lead, 16 Nov .51
        │
        ▼
4 PEOPLE (after the review)
  ◉ Guide, interim ........... .43
  ○ Start-here + who-does-what .73.2
  ○ Onboarding, skills ... .44 .73.1
        │
        ▼
5 REVIEW 3 Dec ............... .52

Dropped on 2 Nov: per-person task page, task sweeps, data clean-up, data steward, Thursday slot.

Task state lives in Beads; this table only shows the shape. As of 2 Nov 2026, updated 7 Nov.

SCQ

The wider question of how we work now that AI is our main interface (Level 1), the original Level 2 text and the team's evidence are in the background.

Situation: We keep two kinds of thing: reference material (docs, plans, SOPs) and tasks. Initiative records live in this repository and projects here or in Google Docs. Tasks are split across Asana for Media House and Beads and GitHub Issues, in several repositories, for operations and planning. More and more of the work goes through AI, which reads and writes these systems for us.

Complication: The line between the systems is fuzzy, so people don't know where to look or log, and copying between them makes a second queue. Many tasks are duplicated, stale, or missing an owner, next step and priority. People can't check what AI tells them against a list they trust, so they fall back to their own lists. No view shows the work at project level across the tools, or gives collaborators who don't use these tools a simple place to follow work. The causes and fixes are in root causes below.

Question: Where do we keep reference material and tasks, and how do we connect them, so that people and AI can both find, update and report on work without extra cognitive load?

Goal tree

Agreed with Rufus on 9 Oct 2026; three conditions and CSF2's dependencies were added by the team on 12 Oct, and CSF2's condition was amended on 13 Oct (weekly plans are flow, priority is state). CSF4, CSF5 and CSF6 were amended on 2 Nov to work at the level of projects, not tasks (Rufus: "clean projects, not clean tasks"); the earlier wording is in the LTP report. CSF is a critical success factor, NC a necessary condition. The full tree and diagram are in the LTP diagrams.

Goal: Everyone, human and AI, knows what to do next and the processes
      around it (how to plan, where to record reference material and
      tasks, how to update them), and trusts that information
├─ CSF1 Project plans are recorded in a common way
│   ├─ NC Each significant project has a plan document, not only tasks
│   └─ NC Planning techniques (SCQ, issue tree, LTP) on offer   (nice to have)
├─ CSF2 Weekly and monthly planning follows one shared process   (needs CSF1, CSF5)
│   └─ NC Priority is kept as state on initiative records; weekly plans only note changes
├─ CSF3 Everyone knows where each kind of thing lives, reference material and tasks
├─ CSF4 Each project shows its objective, owner and next goal   (amended 2 Nov)
│   ├─ NC Significant projects have an LTP or issue tree
│   ├─ NC Each project links to its main tracking item
│   └─ NC Tasks are the project owner's to keep, with their team
├─ CSF5 Project records stay current: status, next goal, no duplicates   (amended 2 Nov)
│   └─ NC The weekly planning sweep checks project records, not tasks
└─ CSF6 Work is visible by project, and each person sees theirs in the Monday plan   (amended 2 Nov)
    ├─ NC A quick human overview, AI-readable underneath
    ├─ NC People can check what AI tells them against records they can see
    └─ NC Less tech-savvy collaborators can see and discuss work with us

Root causes and fixes

The four candidate core causes from the current reality tree, with the fixes from the prerequisite tree.

Conflicts and how we resolve them

From the two evaporating clouds and the other conflicts discussed on 12–13 Oct; resolutions are the team's.

The planning system (how we'll work)

Being tried out in the trial, from the LTP's task routing test, as amended on 2 Nov:

Media House's own work      → Asana
Everything else             → Beads, in the repository
                              of the work's record
Work that spans both        → one owning record;
                              the other tool links to it
Requests for Media House    → request inbox file in the
                              content repository
Initiative priority         → stars on initiative records,
                              reset monthly or quarterly
Monday                      → team plan: projects, owners
                              and each one's goal
Tasks                       → the project owner's, with
                              their team

The full write-up will be a short guide, "How we plan and track work": interim version published (22 Oct), finalised after the trial review, by 10 Dec, and published on planning.lifeitself.org, replacing the out-of-date parts of the workflow. A short briefing for the team covers what was decided and what changes for the trial.

Open questions

• Where exactly is the line between Asana (Media House) and Beads/GitHub? Uriel proposes public-facing and outside-collaborator work in Asana, and infrastructure, code and internal planning in Beads/GitHub. To agree in the first trial meeting (lip-tqk.23). ✅ Answer. By team: Media House's own work in Asana, everything else in Beads; Uriel's broader "public-facing" line was not taken, since only Media House works in Asana (Rufus, 2 Nov 2026; Uriel confirmed).
• For operations and planning work, Beads or GitHub Issues, and what happens to existing GitHub trackers? Tension: Uriel's plan treats GitHub/Beads as one bucket and proposes a GitHub clean-up with labels and due dates, which invests in GitHub Issues as the queue (lip-tqk.23, lip-wz8). ✅ Answer. Beads is the default (Asana for Media House); GitHub Issues is allowed but little used (Rufus, 22 Oct 2026).
• Which repository's Beads holds a task: the planning repository or each initiative's own? In practice, planning tasks here and initiative work in initiative repositories found through the portfolio; not yet agreed (lip-tqk.23). ✅ Answer. The Beads of the repository that holds the work's record; planning's Beads holds only planning-system and cross-initiative tasks (Rufus, 2 Nov 2026; Uriel confirmed).
• During the trial, do Asdra and Fae keep copying requests from GitHub and Beads into Asana each week? (For the post-trial review, lip-tqk.52.) ✅ Answer. No: once it is set up, replaced by a Media House request inbox (until then requests go to Uriel), where each request is one item with required fields, submitted without needing Asana access and triaged weekly at the team plan; promotion work is owned by its Media House task, with a link from Beads if needed (Uriel, 22 Oct 2026; supersedes Rufus's interim answer of the same day).
• Where does the Media House request inbox live (for example a Media House Requests project in Asana fed by a form, or an inbox.md or inbox.csv file in the content repository, with full briefs linked from it), and how are its required fields checked (a form, or a skill with a validator)? (Uriel, Rufus; lip-tqk.65.) ✅ Answer. A file in the life-itself/content repository (B), with links to full briefs, checked by a skill with a validator; Uriel sets it up and picks the format (Rufus, 2 Nov 2026).
• How are priority and dates expressed across tools? Asana uses high, medium and low with due dates; Beads uses P0–P4; our planning convention sets due dates only where fixed (lip-tqk.59). ✅ Answer. 4/3/2/1 stars = Beads P0–1/P2/P3/P4 = Asana high/high/medium/low; due dates only where fixed (Rufus, 22 Oct 2026; in the guide).
• What do Sylvie and Valerie need from a weekly summary, and is the Monday plan enough? Fae and Asdra will work it out with them (lip-tqk.39).
• Where do meeting notes go, and how do their outcomes become tasks? (lip-tqk.54) ✅ Answer. No procedure here: team meeting notes, if any, go in Google Drive, and the distillation is captured in planning records (Rufus, 2 Nov 2026).
• When does the trial end? It started the week of 19 Oct and was planned to run two to four weeks; (lip-tqk.47). ✅ Answer. The trial ends 26 Nov; post-trial review 3 Dec (Rufus, 2 Nov 2026).
• Who may change structure in each system? Uriel proposes one structure owner per system (Uriel for Asana, Rufus for Beads/GitHub), with others commenting; the team and AI agents edit this repository directly. Does "AI may read either system" mean AI may not write to Asana? Low weight, left for the trial to surface. ✅ Answer. For Asana: AI can read and update it, but only the Media House team, and their AI, changes it; anyone may read it and pull reports (Uriel, 22 Oct 2026).
• What does a project pointer in planning hold, and what refreshes its cached status? (Rufus, lip-tqk.56.) ✅ Answer. No pointer files: the sweep reads each project record from its own repository into a cache that feeds portfolio/index.js and Projects by initiative; a stub in planning only where the sweep can't read the record, such as a Google Doc (Rufus, 22 Oct 2026, superseding his earlier same-day answer of frontmatter-only pointer files; lip-tqk.62).
• How are project numbers allocated now that records live in many repositories? (Rufus, lip-tqk.57.) ✅ Answer. Numbered per repository; central references carry a repository prefix, like a Beads prefix (Rufus, 22 Oct 2026).
• What do project priority stars mean: relative within the initiative (LTP) or the data model's absolute scale? (Rufus, lip-tqk.58; cross-tool mapping lip-tqk.59.) Rufus (22 Oct): not sure project stars are useful; if they rank priority they should be assigned centrally. ✅ Answer. Stars only on initiatives, set centrally; project priority is week to week, in the team plan, not a permanent field (Rufus, 22 Oct 2026).
• Do initiative records stay in planning while projects move out? (Rufus, lip-tqk.60.) ✅ Answer. Yes. Areas with their own repos (e.g. sor-community) may keep a finer-grained initiatives list; planning need not track that level (Rufus, 22 Oct 2026).
• Is "draft in Google Docs, then move to Markdown" the rule? (Rufus, lip-tqk.61.) ✅ Answer. Default is drafting with an AI straight into Markdown; use Google Docs only to draft with others in real time (Rufus, 22 Oct 2026).
• Do the Markdown defaults (project records via the portfolio skill; drafts straight into Markdown) hold for Media House, and does a Media House project's Asana project count as its record during the trial? Rufus's calls of 22 Oct; interim answer in the guide is yes to the Asana project. To confirm with Uriel (lip-tqk.64).

Answered questions, with their answers, are in the background.

Key documents

• LTP report, diagrams and ltp.yaml: the full reasoning, from goal and current reality through conflicts and future reality to prerequisites and the task routing test.
• How we plan and track work: the guide, interim version. Briefing for the team (22 Oct).
• How Asana and GitHub work together: Uriel's proposed split, request flow and ownership rules (9 Oct 2026); input to the routing line.
• Beads in Claude cloud sessions: reading works from the cloud with no keys; writing works with a bd-only branch-ref workaround (scripts/beads-branch-sync.sh, tested in a real cloud session 2026-10-23), until Beads ships --ref. Not a priority, since most people work locally (Rufus, 22 Oct 2026).
• Planning at the right height: the tree picture behind "clean projects, not clean tasks" (draft; lip-tqk.76.7).
• Planning skill: the weekly sweep and team plan steps. The old workflow page and Our office were folded into the guide and removed (22 Oct).
• Background: the two-level SCQ with the team's evidence, the 12 Oct key results, the original goal tree with its checks, answered questions and sources.
• Portfolio Establishment: the completed portfolio workstream split out of this project.