Project-management infrastructure — background

Part of Project-management infrastructure. Earlier framing, team evidence and history, moved here on 2026-10-22 when the project page was restructured after the LTP. Kept for history and source links; where it conflicts with the project page, the project page and the LTP report are current.

Situation, complication, question (9 Oct 2026)

Two levels: how we work overall, and our current project-management system. Level 1 is context, shared with the How we use AI guide; this project answers the Level 2 question. Drafted with Rufus on 9 October 2026 as the starting point for the logical thinking process (LTP) analysis. The completed portfolio workstream is Portfolio Establishment.

Level 1: how we work

Situation

• A small, dynamic team, several of them new, with priorities that shift quickly, plus collaborators who are less tech-savvy¹.
• AI is becoming the interface for our work, with apps as storage it reads and writes (How we use AI). Far more work gets done, so each person spans more projects and places².
• For coordination, AI only works well with shared harnesses: written procedures and skills each person installs in their AI, routines that keep tasks and plans tidy, and human-readable summaries where people need them³.
• We are in transition, Rufus included: old ways (working in GitHub or Asana) run alongside new ones (talking to the AI, which builds the views).

Complication

• The team is not in sync on how we plan, track, coordinate and report on work.
• Our systems were built for people coordinating with people, not for work passing between people and AI.
• The shift is hard: people lose familiar interfaces and the hands-on ownership of seeing and moving their tasks, and without harnesses AI adds to the mess rather than reducing it⁴.

Question (draft): How should we plan, track, coordinate and report on work now that AI is our main interface and much of the work is delegated to it?

Level 2: our current project-management system (original)

Situation

• We track reference material (docs, notes, plans, SOPs; AI-readable sources of truth are valued⁵) and tasks (any work, from answering a plan's question to implementation), in Getting Things Done terms.
• Initiative records live in this repository; projects live here or in an A10 / similar Google Doc.
• Tasks are split across Beads, GitHub Issues (several repositories) and Asana (Media House), and the line between them is fuzzy⁶.
• Beads works locally; using it from Claude cloud is getting easier but is not yet routine (lip-tqk.1). Whatever we settle on must also serve other areas, such as the content pipeline.

Complication

• Fragmented: with no clear line between systems, people do not know where to look or log, and copying between systems creates a second queue⁶.
• Dirty data: tasks are duplicated or stale⁷, or missing owner and next step⁸ and current priority⁹, so people cannot act on them.
• Low trust in AI: people cannot tell whether the AI or the data is wrong¹⁰, feel boxed in⁴, and do not know where things live or where to save their own. With no shared harness yet³, they fall back to manual lists or Asana, splitting work further.
• Wrong views: people need work both by project and per person across projects², and readable at a glance. The planning site is verbose¹¹, GitHub sub-tasks are hard to navigate, and less tech-savvy collaborators have no simple place to see and discuss work with us¹.

Question (draft): 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?

Objective and key results as of 12 Oct (superseded)

Everyone at Life Itself, human and AI, knows what to do next and where work is recorded, and trusts that information.

Key results (definition of done; drafted 12 Oct 2026, to confirm), replaced on 22 Oct by the key results on the project page. The cloud result was dropped because Beads from Claude cloud is not a priority (Rufus, 22 Oct 2026); installed update routines became part of the guide and skills result:

• One agreed routing page says where reference material and tasks go, by team: Uriel's plan processed (lip-tqk.23) and Beads vs GitHub Issues decided (lip-wz8).
• Beads works from Claude cloud, or a fallback is decided (lip-tqk.1).
• A team weekly plan exists four weeks running and records priority changes.
• In a sample of about 20 open tasks, at least 80% have owner, next action and priority; no known duplicates between Asana and Beads/GitHub.
• Update routines are written as skills and installed by each team member.
• Each person can see their week on one human-friendly page; Uriel and Sylvie confirm it works.

Approach (as of 21 Oct)

SCQ frames the problem; a logical thinking process (LTP) analysis works on the Level 2 question. Rufus chose LTP over an issue tree because it handles causes better (lip-tqk.24). Steps: goal tree (below), current reality tree, evaporating cloud, injections with a future reality check, then prerequisite tree. The LTP is complete (9–14 Oct 2026, lip-tqk.24 closed): trees and report are in docs/plans/ltp/pm-infrastructure, and the prerequisite steps are tracked as Beads under lip-tqk (mainly lip-tqk.25–.42). The project is now in execution; the SCQ questions and key results are still drafts to confirm. Team summary: briefing (22 Oct 2026; replaced a 21 Oct draft).

Goal tree (9 Oct 2026, superseded)

First step of the LTP analysis of Level 2, worked through with Rufus. Checks are assumptions to test before or during the current reality tree. This seven-CSF version was replaced in the LTP by the six-CSF tree on the project page (priority changes folded into weekly planning, then amended on 13 Oct to priority as state; necessary conditions added in the 12 Oct meeting).

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: however a
│       project is planned, its outcomes (objective, decisions,
│       open questions, status) land in a known shape and place
├─ CSF2 Weekly/monthly planning follows one shared process
├─ CSF3 Everyone knows where each kind of thing lives: reference
│       material (plans, SOPs, docs, artifacts) and tasks
├─ CSF4 Tasks are actionable (what, who, priority/deadline)
├─ CSF5 Records stay current (no duplicates, no stale tasks)
│        └─ NC  Update routines are written and followed by people and AI
├─ CSF6 Priority changes reach the people doing the work
└─ CSF7 Work is visible by project and per person
         ├─ NC  Quick human overview, AI-readable underneath
         ├─ NC  People can check what AI says against records they can see
         └─ NC  Non-technical collaborators can see and discuss it

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. However a project is planned, its outcomes (objective, decisions, open questions, status) land in a known shape and place. There is no shared process for project planning itself. Nice to have, not critical: common planning techniques (for example SCQ, issue tree, LTP) that people can use if they want.
• CSF2 Weekly and monthly planning follows one shared process.
  • NC: the weekly or monthly plan records and announces priority changes. Rufus thinks priority changes are generally fairly minor; the real gap may be communication (someone does not hear of a change) and cross-tasking (for example Sylvie tasks Fae directly). Check: trace the last two or three pivots.
• CSF3 Everyone knows where each kind of thing lives: reference material (plans, SOPs, docs, artifacts) and tasks. The team may be out of sync on all of it, planning included, not just where to log. Check: ask each person where they would log three example tasks.
• CSF4 Tasks are actionable: what to do, who owns it, priority or deadline. Tasks link to their project context (taken as given). Partly confirmed by Rufus: Beads are written as notes for their author and their AI rather than as handoffs, and are poorly updated. Check: sample about 20 open Beads for owner, next action and done-condition.
• CSF5 Records stay current: no duplicates, no stale tasks.
  • NC: update routines are written down and followed by people and AI.
• CSF6 Work is visible by project and per person.
  • NC: a quick human overview, AI-readable underneath. Idea, not confirmed: one page per person or week, a few lines of what is next and what is blocked, with AI write-ups one click deeper. Check: mock one page and show it to Uriel and Sylvie.
  • NC: people can check what AI tells them against records they can see.
  • NC: less tech-savvy collaborators can see and discuss work.

Answered questions

From the original project record and the LTP. Still-open questions are on the project page.

• What happens when Sylvie asks a team member to do something? ✅ Answer. If it is Life Itself or Seeds of Renaissance work, it is prioritised within the team like any other team work. (Rufus, 9 Oct 2026.) Uriel is the air traffic controller (LTP, 13 Oct 2026).
• What external tracker rules and cloud-access procedures do collaborators need? ✅ Answer (routing). Use Beads for planning/agent work and existing GitHub/Asana trackers for their teams; state scopes and link work when tools are mixed rather than duplicating queues. See workflow. Actual Claude-cloud Beads access remains to be tested in lip-tqk.1. (Since tested; see the next question.)
• Can Beads be used from Claude cloud instances: install bd, run embedded Dolt, and bd dolt push/pull (or a JSONL-commit fallback)? lip-tqk.1. This decides whether Beads-first is viable for Asdra, Fae, Sylvie and cloud agents. Partial answer (2026-10-20, tested). Reading works from a cloud session with no keys (a SessionStart hook runs bd bootstrap over HTTPS). Writing via bd dolt push is blocked: Claude's GitHub proxy only accepts branch pushes and Dolt stores data at the non-branch ref refs/dolt/data. Recommended for cloud writes: commit the auto-exported .beads/issues.jsonl to a branch and PR, then bd import locally (simulated, cloud test pending). A second Dolt remote on a branch ref works but is too heavy. Full analysis: Beads in Claude cloud sessions. ✅ Not a priority (Rufus, 22 Oct 2026): most people work locally.
• How do requests cross between systems without a duplicate queue? Uriel's plan has Asdra and Fae pull weekly from GitHub/Beads into Asana "R&S Requests Tracking". ✅ Link, do not copy: a crossover item has one owning record and the other system links to it (LTP tools cloud, 12 Oct 2026; one-page rule in lip-tqk.30). Whether the weekly copy continues during the trial is still open.
• Where should reference material live? ✅ Markdown in Git repositories on GitHub, moved from Drive as projects are touched, not in bulk (Rufus, 13 Oct 2026; lip-tqk.36).
• How does the weekly sweep find projects that live in initiative repositories and Drive folders? ✅ The planning portfolio lists all initiatives and initiative areas with their reference locations, and projects sit in a projects/ folder at each repository root, with status logged per the data model (lip-tqk.32, .33).
• Is priority as state needed at project level, or only for initiatives? ✅ Both, meaning different things: initiatives carry absolute priority, set by Rufus and Uriel; projects carry priority relative within their initiative, set by the initiative owner; weekly plans only reference these (LTP, 13 Oct 2026).
• Who owns weekly planning and the system-work slot? ✅ Rufus and Uriel own weekly planning, with Asdra as Uriel's deputy; the slot is Thursday 12:00–14:00, owned by Rufus for now (LTP, 13 Oct 2026).
• Where do shared agent skills live? ✅ The life-itself/skills repository; the planning repository may keep project-specific skills (Rufus, 22 Oct 2026; lip-tqk.29.1).
• How does the team plan week to week across repos? ✅ Answer (pilot, 2026-10-05). A team planning skill with a live cross-repo sweep (scripts/team_sweep.py) and a next-week plan for the team or one person. Read live, no cache. "Next" is in-progress work plus bd ready by priority, not a due date on every bead; due dates only where fixed. Repos come from active records' github:/tracker: fields as sibling checkouts. Month planning not yet built. See the pilot report; lip-tqk.9.

Earlier open questions not taken up by the LTP

Still open at low weight; raise them in the post-trial review if they matter.

• Where do public-facing change notices go (Uriel proposes a one-line Google Chat message; channel undecided)? Probably comms practice rather than PM infrastructure.
• What further standup, project-review and delegation practices are needed beyond portfolio maintenance? Partly covered by the weekly plan and the weekly handover.
• When does a visual Coggle or spreadsheet help shape a project before durable context and decisions are recorded in Markdown?
• What cross-project prioritisation and consolidation workflow is useful after the basic portfolio works? lip-tqk.9 covers this later extension.

Sources

• Project Coordination — README
• Life Itself Roadmap — September–December 2026
• How Asana and GitHub Work Together — Uriel, 9 Oct 2026 — proposed Asana/GitHub split, request flow and ownership rules; being processed in lip-tqk.23.
• Team meetings of 9, 12 and 13 Oct 2026 (Rufus, Uriel, Fae, Asdra), recorded in the LTP report.