Portfolio Establishment — Plan of Work

Date: 2026-09-23

This is the first delivery phase of Project-Management Infrastructure, not a separate project. Read its agreed issue tree and source links before execution. Beads under lip-tqk holds executable task briefs, acceptance criteria, dependencies and live state; this document explains the delivery sequence and review gates, not a second task queue.

Outcome and approach

Establish a current, source-grounded Markdown portfolio that the coordination team can read and update, with a clear relationship to Beads and enough documentation for another person or AI to continue without this conversation.

Adapt the core documentation and portfolio skill first, use them on a small real sample, then revise them from evidence before full consolidation. Finalise and distil the documentation after the workflow has been exercised. This avoids both migrating into an undefined schema and treating an untested documentation import as a finished system.

Use the executing-plans skill when executing this plan. Start by reading the relevant Bead with bd show <id>; use bd ready to find available work. Do not assume the sequence diagram overrides current task dependencies or newly discovered facts. No implementation or migration is claimed complete by this planning document.

Agreed constraints

• Markdown here is authoritative for initiative/project records and durable context; Beads is authoritative for actionable execution state.
• Initiatives are enduring areas/products. Projects and epics represent bounded work. No mandatory initiative Bead or Markdown file for every small task.
• Initiative labels belong on relevant top-level Beads and standalone tasks; queries include descendants without requiring repeated labels on every child.
• Minimum record content: title, description, owner, lifecycle status, parent where applicable, context/task links, and dated status note. Projects include outcome and next milestone when known; initiatives include enduring purpose and optional objectives/key results.
• Preserve unknowns and distinguish historical source assertions from present-day confirmation. Do not invent owners, statuses or assignments.
• Rufus, Fae and Asdra can update Markdown directly, including through AI. Others may edit when comfortable or submit changes through the maintainer route. Actual cloud Beads access still requires testing.
• Keep task queues in Beads, not Markdown or NEXT.md. Preserve source links and useful existing prose; do not create duplicate project records.
• Read Tao and the spreadsheet as migration sources. Preserve financial fields, historical records and private information. A generated view may supplement the records; do not create another independently maintained portfolio.
• Adapt only the core docs and portfolio skill initially. No polished website, bidirectional sync, weekly-capacity system or wholesale personal-skill migration is required.

Deliverables and their homes

If a helper is needed for initiative queries or a generated overview, choose its exact file and interface after inspecting available tooling. Do not claim existing label filters traverse descendants without verification. Keep generated views reproducible and distinguish them from authoritative records.

Delivery sequence

The full procedural instructions and acceptance criteria are in those Beads. Execution agents should not need to reconstruct them from chat.

flowchart LR
    docs[".4 Core docs + skill"] --> pilot[".10 Sample + walkthrough"]
    pilot --> query[".11 Initiative queries"]
    pilot --> import[".5 Remaining Tao inventory"]
    import --> reconcile[".6 Reconcile sources"] --> confirm[".7 Confirm facts + maintenance"]
    cloud[".1 Cloud Beads access"] --> tracker[".2 External tracker rules"]
    tracker --> locations[".3 Task locations"]
    confirm --> locations
    confirm --> old[".8 Old surface transition"]
    query --> finish[".12 Final docs + handoff"]
    locations --> finish
    old --> finish

Query verification and the remaining import can proceed independently after the sample. Cloud access research can proceed alongside the documentation work. lip-grw remains the initial-establishment milestone, blocked by the sample and verified queries; it is no longer an upstream blocker on drafting the conventions it needs.

Review gates and unresolved checks

Before bulk import: a small representative sample must pass the documented read/update walkthrough. Include an initiative with a project already here, nested or paused work, and labelled-root/unlabelled-child/standalone-task cases. Use actual source evidence; test lifecycle edits on temporary examples rather than falsely closing real work.

Before declaring the portfolio current: the coordination team reviews conflicts and candidate active records. AI can prepare and reconcile evidence but cannot confirm unknown current ownership or activity. Leave unresolved facts visible and create scoped follow-up Beads where needed.

Before team handoff: settle the named maintainer and existing review meeting, verify access and task locations, and ensure old views are clearly identified. The source spreadsheet may retain an accounting role; portfolio migration does not authorise its deletion.

For historical initiative questions: distinguish completed-during-period from all work performed during a period. Verify available events/history before promising the latter. Present membership and creation dates alone do not establish historical activity or historical initiative membership.

Exact schema syntax, source classifications, cloud compatibility and query implementation are execution checks with deliverables. They do not require another general planning round before starting lip-tqk.4. Human confirmations belong at the gates above; no person has been assigned an execution task merely by being named in this plan.

Wider infrastructure work

lip-tqk.1 tests actual cloud Beads access; lip-tqk.2 resolves external tracker locations and collaborator routes. These remain real work, but do not reopen the agreed Markdown-context/Beads-execution distinction or block the local documentation/sample work.

lip-1ie.5 consolidates the wider infrastructure framing once remaining tracker/cadence questions are resolved. lip-tqk.9 (cross-project prioritisation/sweep) is a later extension, not a gate for this portfolio phase. Broader standup, delegation and coordination improvements remain outside this initial delivery. Do not close the entire lip-tqk epic merely because the portfolio phase is complete.

Completion evidence

The handoff should show discoverable records, reconciliation coverage, tested add/update/pause/close instructions, verified initiative queries, current-fact review outcomes, actual tracker links, and an agreed maintenance route. Check metadata, parent references, duplicate slugs and local links; use fixture-based tests if query code is added. Record the actual team walkthrough results. Commit substantive deliverables without unrelated changes.

When the planning system itself ships, draft its changelog entry using the repository convention and check whether a shipped visual warrants a screenshot. This plan and issue-tree update alone are planning content, not a shipped system change.