Project-Management Infrastructure — 2026

Objective

Establish a lightweight, shared approach to project planning, coordination, ownership, delegation, and delivery across Life Itself.

Situation

Life Itself has an older Programs & Projects spreadsheet, Tao’s March–April portfolio work (now a directly maintained snapshot), current project documents here, and a more developed personal planning model in Rufus’s repository. The spreadsheet fell out of regular use roughly eighteen months to two years ago, according to Rufus on 23 September 2026; recent edits do not establish that it is a reliable current portfolio. Tao’s current README and AGENTS.md describe portfolio/index.js as a directly maintained snapshot, with its older Markdown database no longer maintained. The small coordination team of Rufus, Fae and Asdra can update this repository directly.

Complication

Portfolio information and planning conventions evolved in several places, leaving unclear update locations, uncertain current ownership/status and competing views. Markdown here is now agreed as authoritative for portfolio context, with Beads for execution, but the sources still need reconciliation and the workflow needs testing and documenting. External tracker/cloud access and maintenance responsibility also need concrete checks.

Questions and agreed direction

What minimum shared system makes projects, initiatives and executable work clear and accessible? Agreed direction: Markdown records with the minimum metadata/context below, Beads for execution, initiative labels plus descendant queries, and direct coordination-team updates with a maintainer route for others.
How do we establish it and keep it current? Agreed direction: adapt core docs and the portfolio skill, trial a representative sample, reconcile Tao/spreadsheet/current records, confirm facts with the team, and finish the maintenance and AI documentation.

The plan of work turns this framing into bounded Beads with acceptance criteria and dependencies. The remaining checks are part of execution, not a reason to keep expanding the issue tree before starting.

The portfolio must let someone see active initiatives and projects, understand their purpose, owner, dated status and next milestone, find their context and task tracker, and know how to request or make a correction. These needs come from the April job stories, which superseded the earlier coordination hub notes. Weekly capacity planning and prioritisation are related work, but outside the initial portfolio establishment.

Initial scope

Maintain a coherent portfolio view and a single source of truth for project-level information.
Establish a practical pattern for project definition, dependency mapping, sequencing, and task handoff.
Clarify how this repository, Asana, GitHub, Google Docs, and other tools should relate.
Support distributed ownership without requiring the planning system to be perfected before work ships.

Sources

Project Coordination — README
Life Itself Roadmap — September–December 2026
Programs & Projects DB — historical and newer rows, including accounting categories and Xero codes that are not automatically delivery projects.
Tao portfolio — current snapshot and earlier initiative/project material.
Team Coordination Hub Notes — 21 April 2026
Knowledge Management and Information Architecture / Job Stories — 23 April 2026
Rufus’s personal planning model at ~/src/rufuspollock/planning/docs/data-model.md, with related workflow, Beads conventions and portfolio skill — used as adaptation inputs, not adopted wholesale.
Portfolio reconciliation report — source coverage, mappings and remaining fact checks.

Issue tree

What is the minimum infrastructure required now?
- What minimum information does each portfolio record need? ✅ Each record needs a title, short description, owner, lifecycle status, parent initiative where applicable, links to relevant context and Beads, and a dated status note. Projects describe an intended outcome and next milestone when known; initiatives describe an enduring purpose, with objectives/key results where useful rather than mandatory deliverables. Reuse Rufus’s frontmatter conventions where they fit, adding richer SCQ and issue-tree material as needed. Unknown information remains explicitly unknown.
Where should authoritative portfolio records live? ✅ Markdown in this repository is the agreed home for the initial working system, with Beads holding execution. Reconcile existing spreadsheet and Tao material; future visual or spreadsheet views derive from the authoritative records. Trial a small representative sample before full migration.
What distinct job does a project’s Markdown file do versus its Bead? ✅ Markdown holds durable project context: purpose, desired outcome, scope, SCQ, issue tree, hypotheses, decisions, and source links. Beads holds execution: actionable tasks, assignees, dependencies, blockers, and completion state. Link the two; use a Beads epic to group project tasks when useful. Markdown may summarize progress but must not maintain a second task list. AI reads Markdown for context and Beads for what to do next. A small task does not require a Markdown file unless it needs durable framing beyond a clear Bead description.
How should enduring initiatives relate to Beads: labels, parallel records, or epics? ✅ Use initiative labels to associate actual work with an enduring initiative; no standing initiative Bead is required. Epics represent bounded bodies of work. Put the initiative label on the relevant top-level epic or task, and label standalone tasks directly; do not require the same label on every descendant. Initiative views should include descendant work through parent/child relationships as well as directly labelled items. The query implementation is verified; see the initiative task queries in docs/bd-task-conventions.md.
How will initiative views combine directly labelled and descendant work to answer both current-work and historical-work questions, including work associated with projects? ✅ The read-only initiative query combines direct labels, project-to-initiative links and Beads parent/child descendants, with deduplication and explicit exceptions. It supports current work and closed work filtered by completion date. Historical membership is reconstructed from current links, not a historical membership log. See query instructions.
What documentation and skills already exist in Rufus’s planning repository, and which should we adapt for Life Itself? ✅ Adapt the core documentation and portfolio skill first: the data model, Markdown/Beads relationship, and how to add, update, and review projects and initiatives. The source inventory is in the portfolio workstream’s situation. Inventory the other skills, but migrate them only when they support an immediate need; do not copy the personal planning system wholesale.
Where will the settled conventions be documented for people and AI? ✅ Distil the agreed model and workflows into the docs folder as this project completes, and update AGENTS.md to reference them. During shaping, record decisions in this project’s issue tree.
What cadence and ownership model will keep the portfolio current?
- How can team members get information updated? ✅ Rufus, Fae, and Asdra form the small core coordination team and can update this repository directly, including through AI. Others can update directly when comfortable or send changes to a named portfolio maintainer. Project owners remain responsible for confirming their information; the maintainer checks gaps and stale records during an existing planning meeting.
- Who is the named maintainer, and which planning meeting will include the review? ✅ Answer. Rufus, confirmed 2026-09-25. Use a brief check in the existing coordination meeting when needed, not a new meeting or a weekly sweep of every initiative. People can edit directly or send Rufus the initiative link and correction; initiative owners confirm their own information.
What reading view and access instructions do other team members need?
How should duplicate names, parent relationships and conflicting historical owner or status claims be reconciled?
Which projects and initiatives are active now, and who can confirm their ownership and status?
What happens to the old spreadsheet and Tao views after the new portfolio is established? ✅ Answer. Tao's portfolio snapshot and former project-registration process are deprecated; its handbook points to the workflow here. Keep historical sources, not a second editable portfolio. Rufus handles the spreadsheet deprecation notice; accounting uses are preserved.
Must every project start in this repository? ✅ Answer. No. Use either a numbered project record here or an A10 / similar Google Doc, without duplicate registration or a Tao issue. Initiatives are maintained here. Project creation remains WIP; content-production items have a separate workflow under development.
What instructions, examples and AI prompts make record updates straightforward?
How should existing Life Itself records be brought into the chosen conventions? ✅ Answer. Start with Tao’s inventory, reconcile it with the spreadsheet and current project documents, preserve provenance and useful links, and flag conflicts rather than guessing. The representative sample preceded wider consolidation; historical items remain distinguishable from confirmed current work. See the reconciliation report for coverage and dispositions.
Which parts of Rufus’s personal planning conventions should be adopted? ✅ Answer. Adapt the data model, Markdown/Beads distinction and portfolio update workflow; defer other planning skills until they serve an immediate team need. Personal assignee labels and task-list instructions do not override this repository’s Beads role.

Plan of work

See Portfolio Establishment — Plan of Work. Core documentation and the portfolio skill come first (lip-tqk.4); the sample and initiative-query checks precede initial establishment. Consolidation, confirmation, task-location mapping and final documentation follow in the existing lip-tqk work structure. Beads holds the live queue and detailed work briefs.

The portfolio is a workstream of this project, tracked through lip-grw within lip-tqk; it is not a second project. The reconciliation report records completed source mapping and remaining fact checks. The agreed approach is one authoritative Markdown portfolio with derived reading views and a direct or maintainer-assisted update route. A visual overview or spreadsheet can be a view without becoming a second editable database. The earlier alternatives were to make the spreadsheet or GitHub Issues/Projects the authoritative portfolio; neither was selected for the initial working system.

Wider infrastructure questions

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.
What further standup, project-review and delegation practices are needed beyond the portfolio maintenance review?
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.

Earlier source notes proposed a fixed Coggle → issue-tree spreadsheet → Asana/GitHub progression and called the spreadsheet canonical. Those are historical inputs, not the adopted rules. The issue-tree answers and canonical workflow govern this delivery; individual unknown tracker locations remain explicit exceptions in their records.

Current delivery position

2026-09-25: Project filenames now use stable short numbers. Documentation distinguishes initiative maintenance here from the two project routes, with no compulsory Tao issue; Tao points here and preserves its old material as historical. Rufus confirmed the maintenance arrangement above and accepted the handoff (lip-tqk.12 closed); a separate team walkthrough is optional. Tracker cleanup in Tao is a separate audit, not a prerequisite for starting projects.

The sample read/update walkthrough is complete (lip-tqk.10). The wider source inventory is reconciled, the generated portfolio index is available, and initiative-work queries are verified. Current-fact exceptions remain explicit in their records; the maintenance handoff is accepted. lip-tqk holds the wider planning-system execution tree.

Current execution is supported by Rufus’s instruction to start and the completed lip-tqk.4 deliverable on 23 September 2026. Rufus explicitly confirmed portfolio-project ownership in the 23 September conversation. parent: null means the parent initiative is not yet reconciled; the existing initiative:planning Beads label is preserved without inventing a matching initiative record. Record creation date is preserved from the initial repository history (17 September 2026).