Activities - Bootstrap the Team

#	Name	Abbrev.	Guidance	Actions
Kickoff 3
1	Assign the Delivery Manager	BTM-1	Objective Have the project sponsor appoint the Delivery Manager before the Delivery Manager performs any …	Read the 'BTM-1 Assign the Delivery Manager' activity from playbook 'Junior Edda' (workflow 'Bootstrap the Team'). Follow its guidance when assisting me. ## Objective Have the project sponsor appoint the Delivery Manager before the Delivery Manager performs any project work. An AI agent must not appoint itself or infer a person. ## Procedure 1. Obtain the sponsor's explicit appointment. 2. Record it in `docs/project/DELIVERY_OWNERSHIP.md` with: - Delivery Manager name and contact; - start date and timezone; - decision authority and approval boundaries; - escalation route and response expectation; - backup/delegate; - responsibility for Charter ownership, cadence, AIN oversight, and Risk/Problem tickets. 3. Confirm the appointee accepts the role. 4. If no person is available, record the sponsor as interim DM with an expiry/review date; do not leave ownership implicit. ## Completion evidence The assignment record exists, names both sponsor and DM, contains authority boundaries, and includes appointment and acceptance timestamps. Staffing is a human/sponsorship action; the activity deliberately has no executing Mimir Agent.
2	Absorb Vision/Scope Handover	BTM-2	Objective Normalize validated business evidence into docs/project/VISION_SCOPE_HANDOVER.md, the single handoff consumed by Charter drafting and …	Read the 'BTM-2 Absorb Vision/Scope Handover' activity from playbook 'Junior Edda' (workflow 'Bootstrap the Team'). Follow its guidance when assisting me. ## Objective Normalize validated business evidence into `docs/project/VISION_SCOPE_HANDOVER.md`, the single handoff consumed by Charter drafting and ESM. ## Required external inputs Use the latest approved outputs from Testing a Business Idea when that playbook was run: Customer and USP Dossier, Experiment/Test Charter, Approved Learning Card, Feasibility Decision, and Recommended Next Experiment. The external playbook currently ends at Approve the Learning and Decision; do not look for a nonexistent activity named “Prepare handover package for Junior Edda.” Equivalent sponsor-approved evidence may be used when Testing a Business Idea was not run. ## Procedure 1. Inventory each source with title, version/date, owner, and location. 2. Fail fast if there is no approved feasibility decision or if the decision is `stop`. An `adapt` decision must state the approved adaptation before continuing. 3. Extract: target customer/personas; jobs/pains/gains; USP; observed evidence; assumptions; product scope; excluded scope; constraints; success/failure criteria; outstanding risks; recommended next step. 4. Preserve provenance. Label every item `observed`, `approved decision`, or `assumption`. 5. Reconcile contradictions with the sponsor; do not silently choose one source. 6. Write the normalized document and an unresolved-questions table with owner and due date. ## Completion evidence The handover exists at the canonical path, cites every source, contains an explicit continue/adapt decision, distinguishes evidence from assumptions, and has no ownerless blocker. Record its version and approval.
3	Draft Charter v0	BTM-3	Objective Create the executable project-management contract at docs/project/CHARTER.md from the normalized handover. Charter v0 must …	Read the 'BTM-3 Draft Charter v0' activity from playbook 'Junior Edda' (workflow 'Bootstrap the Team'). Follow its guidance when assisting me. ## Objective Create the executable project-management contract at `docs/project/CHARTER.md` from the normalized handover. Charter v0 must be approved before Inception starts. ## Plan first Enter the ADE's planning mode when available. Otherwise write a step-by-step drafting plan. Sections may be drafted in parallel only when each worker writes a separate section and one final worker checks cross-section consistency. ## Required structure 1. Goals — outcome, measure, target, target date, evidence source, owner. 2. Team Roster — person/agent, mission, authority, owned workflows/artifacts, meetings, backup. Include team maturity: `L2 \| early-L3 \| late-L3 \| L4`, supporting evidence, assessor, and assessment date. 3. Variables We Track — one row per stable `variable_id` with definition, unit, source system, exact query/command, aggregation/window, freshness limit, Green/Yellow/Orange/Red or Green/Red thresholds, missing-data behavior, owner, and `gating_policy: observe \| pause_new_work \| block_release`. 4. Artifact Coverage Decision — artifact, required?, canonical path/system, owner, freshness rule, validation command. 5. Cadence — current iteration-length decision process, ceremonies, participants, trigger, duration; recurring meetings only when team size is greater than one. 6. Release Roadmap — alpha/beta/gamma/RC, explicitly marked aspirational until EST validates it. ## Procedure and gates - Cite every statement back to the Vision/Scope Handover or label it as an assumption. - Use stable IDs for variables and artifacts; display names may change without breaking history. - Define `Unknown` handling separately from performance bands. Missing/stale evidence is never Green. - Obtain explicit sponsor and Delivery Manager approval. ## Completion evidence All six sections exist; every variable is mechanically measurable; every required artifact is locatable and testable; maturity has evidence; gating policies are explicit; the roadmap is labeled aspirational; approval and version `v0` are recorded.
Inception 1
4	Run ESM with Client, Walk Mockups	BTM-4	Objective Invoke the existing Envision the System (ESM) workflow with the client and establish the …	Read the 'BTM-4 Run ESM with Client, Walk Mockups' activity from playbook 'Junior Edda' (workflow 'Bootstrap the Team'). Follow its guidance when assisting me. ## Objective Invoke the existing Envision the System (ESM) workflow with the client and establish the approved product/experience baseline for architecture and delivery. ## Required inputs - `docs/project/VISION_SCOPE_HANDOVER.md`. - `docs/project/CHARTER.md` v0, especially Goals and Team Roster. - Named client decision-maker and scheduled review point. ## Procedure 1. Enter the ADE's planning mode when available; otherwise write a short execution plan before changing artifacts. 2. Invoke ESM activities in their defined dependency order. Pass the normalized handover, Charter goals, personas, constraints, and unresolved assumptions as context. 3. Where ESM explicitly permits fan-out, parallelize independent read-only analysis or distinct-output work, then run its convergence checks. 4. Walk every mockup and material journey decision with the client. Record decisions, rejected alternatives, and open questions. 5. Resolve or explicitly defer blocking questions before handing off to DTA. ## Completion evidence All required ESM artifacts exist at their canonical project locations, identifiers agree across journey/IA/dialogue/feature/mockup artifacts, the client approval record names the approved baseline, and no unresolved question prevents architecture. Merely generating mockups does not complete this activity.
Elaboration 2
5	Complete Inception and Elaboration	BTM-5	Objective Carry the approved ESM baseline through the existing Inception and Elaboration workflows until the …	Read the 'BTM-5 Complete Inception and Elaboration' activity from playbook 'Junior Edda' (workflow 'Bootstrap the Team'). Follow its guidance when assisting me. ## Objective Carry the approved ESM baseline through the existing Inception and Elaboration workflows until the repository is ready for automated assessment and the first Construction iteration. ## Procedure 1. Verify Workflow Envision the System (ESM) completed and its client approvals are recorded. 2. Run Define Architecture (DTA) and approve the resulting SAO. 3. Run Deploy Software Process (DSP). 4. After DSP prerequisites are satisfied, run Estimate the Project (EST) and Design & Deploy Cloud Infra (DCI) in parallel when their read/write footprints do not conflict. If the ADE supports parallel workers, dispatch one bounded worker per workflow and converge on cost, environment, and release assumptions. 5. Run Design & Deploy CI/CD (DCD) after DCI. 6. Run Bootstrap Project (BSP) after DCD. 7. Execute the phase-appropriate Test Automation Framework (TFK) activities required before the first feature. 8. At convergence, verify that SAO, process configuration, estimates, runnable repository, test commands, deployment path, rollback path, and required secrets/contracts agree. ## Failure handling Stop at the first failed workflow gate. Do not skip a dependency because another worker finished. Do not claim readiness from generated files alone; execute the repository's documented verification commands and inspect the target environment where applicable. ## Completion evidence Create `docs/project/ELABORATION_READINESS.md` listing each invoked workflow, its authoritative output, verification command/result, unresolved risk, and approval. Every required row must be PASS before Set Up Huginn begins.
6	Set Up Huginn	BTM-6	Objective Configure Huginn to execute the AIN assessment contract manually and, when appropriate, on a …	Read the 'BTM-6 Set Up Huginn' activity from playbook 'Junior Edda' (workflow 'Bootstrap the Team'). Follow its guidance when assisting me. ## Objective Configure Huginn to execute the AIN assessment contract manually and, when appropriate, on a schedule. Huginn observes and reports; it does not redefine Charter variables or bypass delivery gates. ## Required inputs - Approved Charter v0 at `docs/project/CHARTER.md`. - A runnable repository with its delivery/test commands. - Completed Inception and Elaboration readiness evidence. - A selected GH or Jira ticket adapter and credentials supplied through the project's approved secret mechanism. ## Procedure 1. Inspect existing Huginn configuration and repository automation before creating anything. 2. Create `docs/project/HUGINN_ASSESSMENT_CONTRACT.md` containing: - repository and environment identity; - manual trigger and schedule; - exact source/query/command for every Charter variable; - assessment snapshot boundary and freshness limit; - ticket system, project/repository, labels/types, and stable concern key; - expected-artifact paths and staleness checks; - notification and escalation destinations; - retry, timeout, and overlapping-run policy. 3. Configure one AIN run at a time per project. A second trigger must reuse or wait for the active run, not race it. 4. Run AIN once manually against known data. 5. Verify the persisted Assessment Run Record, ticket action, throughput result, coverage result, and final report. 6. Enable scheduling only after the manual run passes. ## Failure handling If a source, credential, query, or ticket adapter is missing, record the exact blocker and stop. Never substitute invented data or mark an unmeasurable variable Green. ## Completion evidence The contract is committed, a manual run has a stable run ID and complete report, all side effects are idempotent, and the next scheduled time is visible when scheduling is enabled.
Construction 2
7	Run First Iteration, Ship Increment	BTM-7	Objective Run the first complete delivery cycle with the team and ship one bounded, accepted …	Read the 'BTM-7 Run First Iteration, Ship Increment' activity from playbook 'Junior Edda' (workflow 'Bootstrap the Team'). Follow its guidance when assisting me. ## Objective Run the first complete delivery cycle with the team and ship one bounded, accepted increment while the Charter assumptions are still provisional. ## Preconditions - Charter v0 is approved. - ESM, DTA, DSP, required estimation/infrastructure/CI-CD work, BSP, and applicable test-framework setup are complete. - Huginn can run AIN manually even if scheduling is not yet enabled. - One candidate goal can fit the cadence selected by RIN. ## Procedure 1. Invoke Workflow Run the Iteration (RIN); do not duplicate its activities here. 2. Keep the Delivery Manager and team together for this first pass. Record every place where the Charter, tooling, ownership, or activity guidance is insufficient. 3. When RIN starts MIN, launch or schedule Assess the Iteration (AIN) as the independent supervisory stream. If the ADE supports subagents/background tasks, keep AIN separate from the MIN execution context. 4. Preserve every PIN/MIN human gate. Parallel execution does not authorize merging, releasing, purchasing, or changing scope. 5. Ship only when the selected increment passes its declared acceptance, regression, and release checks. ## Completion evidence Record the iteration goal, manifest/milestone, release or deployment identifier, acceptance result, latest AIN report, unresolved tickets, and observed process defects. A plan without a shipped and verified increment does not complete this activity.
8	Hold Retrospective, Update Charter	BTM-8	Objective Close the first shipped iteration, test the assumptions in Charter v0 against observed evidence, …	Read the 'BTM-8 Hold Retrospective, Update Charter' activity from playbook 'Junior Edda' (workflow 'Bootstrap the Team'). Follow its guidance when assisting me. ## Objective Close the first shipped iteration, test the assumptions in Charter v0 against observed evidence, and publish an approved Charter v1. ## Required inputs - `docs/project/CHARTER.md` at v0. - The first iteration goal, manifest, release evidence, and Definition-of-Done result. - The latest Iteration Assessment Report and all open Risk/Problem tickets. - Any Iteration Improvement Proposals (IIPs). - Participants from the Charter Team Roster. ## Procedure 1. Create `docs/project/retros/BOOTSTRAP_RETRO.md`. 2. Record what was expected, what happened, evidence, and consequences. Separate facts from opinions. 3. Review every Charter section: - goals and success measures; - roster, authority, and ownership; - team maturity classification and its evidence; - tracked-variable measurement contracts and thresholds; - required-artifact coverage; - meeting cadence; - aspirational roadmap. 4. Review each IIP. Record `accepted`, `rejected`, or `deferred`, with owner and reason. 5. Update `docs/project/CHARTER.md` to v1. Add a dated change log; never silently overwrite v0 assumptions. 6. Obtain explicit sponsor/Delivery Manager approval. ## Completion evidence - Bootstrap retrospective exists and cites iteration evidence. - Charter says `Version: 1`, contains the dated diff, and has no undefined variable source, threshold, owner, or gating policy. - Every IIP and open Risk/Problem ticket has a disposition or named owner. - Approval is recorded. Do not declare Bootstrap complete without it.

Activities in Bootstrap the Team