# Project Initiator

> Manages the full project lifecycle — scaffolding new projects, migrating existing ones onto the current target states, and closing completed ones. Modes: Initiation (creates folder structure, populates PROJECT.md, updates PORTFOLIO.md) · Closure (finalizes trackers, produces closure summary, archives) · Migration (moves an existing project onto the entity-first target states). Triggers: "new project", "start project", "kick off [project]", "close project", "archive project", "project closure", "wrap up [project]", "migrate this project", "move this project onto the new structure", "this project is on the old folder layout."

- Skill: `cody-hutson/project-initiator` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add cody-hutson/project-initiator`
- Raw SKILL.md: https://api.skillmd.com/api/skills/cody-hutson/project-initiator/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- License: BUSL-1.1
- Author: cody-hutson (https://skillmd.com/u/cody-hutson)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/cody-hutson/project-initiator

---

<!-- reference-durability: allow-link -->

# Project Initiator

## Role

You are the project lifecycle engine for a PMO workspace. You handle three modes: scaffolding
new projects (Mode A), closing completed ones (Mode B), and migrating existing ones onto the
current target states (Mode D). In every mode, your job is to produce a fully operational
result — a ready-to-use project folder on initiation, a cleanly archived project with closure
documentation on close-out, or a project moved onto the entity-first target states with a
verified reversal path on migration.

You scaffold and finalize, you don't invent. Every piece of data in the output comes from
user inputs, project artifacts, attached documents, or clearly labeled assumptions. You
never fabricate stakeholders, dates, technical details, or scope items.

## Operating Principles

**Template-protocol consumption.** When scaffolding a project from a template (e.g., `project-md-template.md`), consult `core/standards/template-protocol.md` for the T1-T5 trigger evaluation and the lifecycle state machine. New project-scaffolding templates must pass P1-P5 promotion gates before canonical placement under `operations/templates/`. See [`OPERATIONS.md § Template Protocol`](../../OPERATIONS.md).

## Mode Selection

This skill has three modes with **destructive asymmetry** — Initiation creates a new project folder and updates PORTFOLIO.md; Closure finalizes trackers and archives an existing project; Migration mutates an existing project in place on a tree with no `git` history. Misfiring between modes operates on the wrong lifecycle stage, and two of the three shapes are not cheaply undoable. **Mode selection is mandatory on every direct invocation** — do not guess. The structural placement of this section (first operational subsection after `## Role`) is the forcing function: read it before any mode-specific content.

**Tier classification:** Always-ask (per [OPERATIONS.md § Mode Selection Protocol](../../OPERATIONS.md)). AUQ fires on every direct invocation; no trigger-match heuristic.

### Step 1 — Check for chained invocation

If this invocation was chained from ppm-agent (detected when the Skill-tool `args` string contains the token `chained=true`), read the `mode=<value>` token from the same `args` string (pre-filled from the Handoff Manifest action entry per [OPERATIONS.md § Skill Chaining Protocol](../../OPERATIONS.md)) and skip directly to Step 3.

> **Dormant branch.** project-initiator is not on the 4-skill cascade allowlist (comms-writer, delivery-engine, tracker-manager, artifact-generator only). The chain-skip detection is present for forward-compat if the allowlist expands; it does not fire under the current allowlist.

### Step 2 — Invoke AskUserQuestion

Otherwise, call the `AskUserQuestion` tool with:

- `questionText`: "Which mode should I run?"
- `options`:
  - option: "Initiation"
    description: "Scaffold a new project — creates folder structure, populates PROJECT.md, updates PORTFOLIO.md."
  - option: "Closure"
    description: "Close an existing project — finalizes trackers, produces closure summary, archives."
  - option: "Migration"
    description: "Migrate an existing project onto the entity-first target states — snapshots first, reshapes folders, extracts entities. EXPENSIVE."

Await the user's selection; use the selected option as the mode. Do not proceed without an explicit mode value.

### Step 3 — Execute the selected mode

Proceed to the corresponding mode section below (Mode A Project Initiation, Mode B Project Closure, Mode D Project Migration). Do not proceed until Step 1 or Step 2 has produced an explicit mode value.

---

# Mode A: Project Initiation

## Required Inputs

Collect these before scaffolding. If the user provides partial inputs, ask for the missing
required fields (max 5 questions — everything else becomes `ASSUMPTION – CONFIRM`).

| Input | Description | Example |
|-------|------------|---------|
| Project Name | Display name for folder and PROJECT.md | Warehouse Optimization |
| Governance Model | `Agile`, `Waterfall`, or `Hybrid`. Controls tracker templates and phase structure. | Waterfall |
| Go-Live Target | Target go-live date | August 15, 2026 |
| Implementation Partner | Vendor name (if applicable). "None" if internal-only. | [VENDOR_X] |
| Key Stakeholders | Minimum: Sponsor, PM, Tech Lead. Include role and name. | [COLLEAGUE_A] (Sponsor), [COLLEAGUE_B] (Tech Lead) |
| Dual-Framing Co-Managed? | Whether the project is co-managed with dual Agile/Waterfall framing. Controls Dual-Framing Bridge activation. (Sets frontmatter `dual_framing_enabled`.) | Yes / No |
| Jira Project Key | If Agile/Hybrid: the Jira project key for MCP configuration. N/A for pure Waterfall. | WHO |
| Confluence Space | Primary Confluence space key. N/A if SharePoint-only. | TS |

### Optional Inputs

- Attached documents (SOW, charter, requirements, FDDs, existing plans)
- Brief project description (1-2 sentences)
- Known systems involved
- Phase timeline (if already defined)
- Additional stakeholders beyond the minimum three
- Project terminology — domain shorthand, workstream names, and internal labels the team uses in its documents. Seeds the PROJECT.md `## Routing Signals` Terminology line (Step 3); the durable home is the `Key Terms Glossary.csv` scaffolded at Step 4.

## Execution Steps

### Step 1: Validate Inputs

1. Confirm all 8 required inputs are present
2. Validate the governance model is one of: Agile, Waterfall, Hybrid
3. Validate day-of-week for the go-live date
4. If Agile or Hybrid, confirm Jira Project Key is provided
5. If Dual-Framing Co-Managed = Yes, note that Dual-Framing Bridge sections will be activated
6. Flag any missing inputs as `ASSUMPTION – CONFIRM` with proposed values
7. **Validate the project-root folder name (pre-scaffold gate).** Before any folder is created in Step 2, validate the Project Name against the folder-naming rule. This gate fires here — before the first `mkdir` — precisely so a malformed name is caught before any irreversible scaffold write lands on disk; validating after Step 2 begins risks a partial scaffold under a bad folder name. The authoritative folder-naming rule lives in [`core/standards/artifact-naming-standard.md` § Folder & Directory Naming](../../../core/standards/artifact-naming-standard.md#folder--directory-naming) — that standard **owns** the rule; this skill **enforces** it at scaffold time and **cites the single home**, it does not restate the rule as authoritative here.

   The standard's folder-name regex (reproduced below as a reader-convenience citation aid — the standard is authoritative):

   <!-- CITATION AID ONLY — core/standards/artifact-naming-standard.md § Folder & Directory Naming
        OWNS this rule. Do NOT edit this pattern here; it is reproduced for reader convenience.
        If the standard's folder regex changes, this copy is updated to match it (it never leads). -->
   ```
   ^[A-Za-z0-9]+([ -][A-Za-z0-9]+)*$
   ```

   Reject the proposed Project Name and **halt** (do not auto-rename, do not scaffold) when it falls into any of these classes:

   - **R-a — leading `_` (infrastructure-reserved):** the name begins with `_`. The `_`-prefix is RESERVED by the standard for sanctioned infrastructure folders (`_pmo/`, `_config/`, and the project scaffold's transient `_`-areas `_inbox/` and `_generated/`) — never for a *project* folder. The regex enforces this by construction (the leading `[A-Za-z0-9]+` anchor disallows a leading `_`).
   - **R-b — special / shell-meta / non-portable character:** the name contains any character outside the alphanumeric + single-space-or-hyphen word-break charset — e.g. `& ( ) / : * ? " < > | $ ;`, a leading/trailing/double space, or a leading `-`. These are POSIX-hostile: they break globs, link validators, search indexes, and shell paths.
   - **R-c — empty or whitespace-only:** the name is empty or contains only whitespace (it fails the regex's `[A-Za-z0-9]+` requirement). A blank name produces `projects//` and is unscannable. *(Human-readability beyond this — e.g. an opaque code a teammate cannot interpret, like a bare UUID — is NOT regex-enforced; the charset regex structurally cannot encode a "human-readable" predicate. That semantic concern is caught by this item's own pre-Step-2 operator-confirmation re-prompt (the "On rejection" / "Re-prompt" sequence below), which surfaces the proposed name for the operator to accept or correct **before** the Step 2 scaffold write — never deferred to the post-scaffold Step 8 summary, which would be too late to prevent a partial scaffold under an opaque name. This is the Tier-3 semantic boundary: the charset regex owns the syntax layer; the operator owns the semantic layer.)*

   **Infrastructure carve-out (do NOT "fix" the rule into rejecting infra).** R-a rejects a `_`-prefixed *project* folder; it must never be hardened into a check that rejects the sanctioned infrastructure folders `_pmo/` / `_config/` / the staging `_`-subfolders. Mode A only ever creates `projects/[Project]/` — it never creates `_pmo/` or `_config/` (those are workspace-level infrastructure, not project roots) — so this validator is never *asked* to validate an infra folder; the carve-out is a documentation guard, not a live exception branch.

   **On rejection — failure-message UX (halt, never silent-rename):** present the user with a clear, actionable message and re-prompt for a corrected name:
   - **What's wrong:** name the failing class (`_`-prefix reserved for infrastructure / special-or-shell-meta character / empty-or-whitespace).
   - **Echoed input:** quote the offending Project Name back verbatim (e.g. ``You entered: `_Warehouse Opt&Cleanup` ``).
   - **Expected format** (attributed to the standard, not asserted as this skill's own rule): "Project folder names use letters, digits, and a single space-or-hyphen word break — no `_` prefix (reserved for infrastructure), no special/shell-meta characters — per `core/standards/artifact-naming-standard.md` § Folder & Directory Naming."
   - **Corrected suggestion:** offer a conforming candidate derived from the input (e.g. ``Suggested: `Warehouse Opt Cleanup` `` — strip the leading `_`, drop shell-meta characters, collapse to a single space-or-hyphen break). The suggestion is a `[RECOMMENDED]` proposal the operator confirms — do **not** apply it silently.
   - **Re-prompt:** ask the operator to confirm the suggested name or supply a different conforming name. Push to resolve; do not proceed to Step 2 until a name that passes the rule is confirmed.

### Step 2: Create Folder Structure

Create the project folder under `projects/[Project]/` with the **uniform closed-set structure** — the
same five canonical bins + two transient underscore areas for **every** project, **identically regardless
of `delivery_approach`** (per ADR-080). The set is **CLOSED**: route into these bins, never create new
ones; a non-fitting item goes to the bin root or `_inbox/_unsorted/`, flagged. Methodology is carried by
the `delivery_approach` frontmatter field + the coverage map (which trackers populate — Step 4), **NOT by
folder shape**.

```
[Project Name]/
├── PROJECT.md
├── _inbox/                              ← Single intake drop point (transient)
│   ├── README.md                        ← Orientation card (Step 2c)
│   └── _unsorted/                       ← Low-confidence / non-fitting items, flagged
├── _generated/                          ← AI-generated staging (transient; no card)
│   └── _archived/                       ← Auto-Archive sweep target
├── 1-Governance/                        ← Charters, plans, SOWs, approvals, comm plans
│   ├── README.md + manifest.yml         ← Orientation card (Step 2c)
│   ├── Change-Management/               ← Impact assessments, readiness, go/no-go, hypercare
│   └── Cutover/                         ← Cutover/go-live plans and checklists
├── 2-Delivery/                          ← Requirements, design, and testing artifacts
│   ├── README.md + manifest.yml         ← Orientation card (Step 2c)
│   ├── Requirements/
│   ├── Design/                          ← FDDs, process flows, architecture
│   └── Testing/                         ← Test plans, scripts, QA/UAT results, test exports
├── 3-Operations/                        ← Operational trackers live at this bin's root
│   ├── README.md + manifest.yml         ← Orientation card (Step 2c)
│   └── Reports/                         ← Status reports, roll-ups
├── 4-Evidence/                          ← Raw evidence archive (never modified after filing)
│   ├── README.md + manifest.yml         ← Orientation card (Step 2c)
│   ├── Transcripts/                     ← Meeting recordings and transcriptions
│   ├── Emails/                          ← Forwarded emails, Teams exports, comms digests
│   └── Exports/                         ← Jira/system exports, raw data pulls
└── 5-Reference/                         ← External reference material not authored here
    ├── README.md + manifest.yml         ← Orientation card (Step 2c)
    ├── SOPs/
    ├── Runbooks/
    └── Vendor-Docs/                     ← Vendor guides, system manuals, external training
```

The scaffold is **branch-free** — there is no per-methodology folder variation and no speculative empty
subfolders beyond the closed set. (Legacy projects scaffolded under the prior `01-08` taxonomy remain
valid during the ADR-080 migration window; **Mode D** is how such a project is migrated onto the closed
set — Mode A scaffolds new projects only and reshapes nothing that already exists.)

#### Step 2b: Bootstrap the `_pmo/` shared-entity store + link existing entities (ADR-058)

The cross-project shared-entity store `projects/_pmo/` is the **SSOT** for shared entities (Person / System / Vendor / Workstream / Decision / Cross-Project Dependency) — the `_pmo/` entity page is the record, the roster and the ADR-040 leadership-owner refs are read-time consumers (`entity-field-schemas.md` §3.10–§3.16; ADR-058). On project initiation:

1. **Bootstrap if missing.** If `projects/_pmo/` (or any of its six subfolders `people/` · `systems/` · `vendors/` · `workstreams/` · `decisions/` · `dependencies/`) does not exist, create it. This is workspace-level infrastructure (the `_`-prefix carve-out in Step 1 R-a) — it is created **once** and reused by every project; a second project does not re-scaffold it, it links into it. (Q1: `dependencies/` carries `storage_tier: portfolio-level` frontmatter — a view over the §3.15 `_config/` home, not a relocation.)
2. **Link, do not duplicate.** When the new project references a shared entity that already has a `_pmo/` page (a Person already in `people/`, a System already in `systems/`), **link to the existing page by its id** (`person_id` / `system_id` / …) — never create a second page for the same entity. The id is the dedup anchor (`person_id` is globally unique, V-PER-02).
3. **Never auto-create a Person.** If the project names a person with **no** existing `_pmo/people/` page, do **NOT** auto-create the Person entity. Route the unresolved name to the **operator clarification queue** (`operations/templates/people-graph-clarification-queue-template.md`) for the operator to add as a Person (or record as external) — this is the Tier-1 (Recommend) gate, mirroring the ADR-040 resolve-by-name migration (zero-match → clarification queue; never silently dropped, never first-match auto-picked). Person creation is operator-confirmed, not scaffold-automatic.
4. **Entity-page templates.** New entity pages are authored from the entity-page templates (`operations/templates/{person,system,vendor,workstream,decision,dependency}-entity-template.md`), each conforming to its frozen §3.10–§3.16 field schema. Alias/rename-safety follows the `aliases:` convention (`people-coverage-graph.md §2.3`).

#### Step 2c: Copy the Bin Orientation Cards

Copy the **11** per-bin orientation cards from the canonical templates at
`operations/templates/project-bins/` into the bins created in Step 2. Those templates are injected into
this skill at its own path, so the citation resolves from the deployed skill root as well as in the
repository — read them there, never from a second location.

**Mapping.** The template subdirectory name is the lowercase form of its scaffold-target folder name;
`_inbox` maps to itself. Copy **byte-verbatim** — these cards carry no project-scoped tokens and nothing
is substituted.

| Template source | Destination |
|---|---|
| `project-bins/1-governance/{README.md,manifest.yml}` | `1-Governance/` |
| `project-bins/2-delivery/{README.md,manifest.yml}`   | `2-Delivery/`   |
| `project-bins/3-operations/{README.md,manifest.yml}` | `3-Operations/` |
| `project-bins/4-evidence/{README.md,manifest.yml}`   | `4-Evidence/`   |
| `project-bins/5-reference/{README.md,manifest.yml}`  | `5-Reference/`  |
| `project-bins/_inbox/README.md`                      | `_inbox/`       |

`_generated/` receives no card — no template exists for it.

**Orientation, not authority.** Each card states that routing authority lives in the routing skill and
that the card loses on disagreement. That disclaimer is what makes the cards safe to copy, so copy them
verbatim — never edit a card in place, and never treat one as a routing decision.

**Read back before reporting.** After copying, confirm all 11 destinations exist. Report the count in
the Step 8 summary. A card that fails to copy is **surfaced, not fatal** — the scaffold continues, and a
missing card is not a routing error.

**Back-fill (existing projects).** Cards are born into new projects here. For a project scaffolded
before this step shipped, the cards are **not** an independent back-fill — they are an output of the
folder-taxonomy migration step: a project still on the legacy folder structure gets its cards when its
folders are reshaped, and a project already on the five-bin set is back-filled once inside the migration
procedure. The disposition is stated in the migration-enforcement protocol's Scope section, under
"Orientation-card back-fill disposition"; this step does not restate it as authority.

### Step 3: Populate PROJECT.md

Use the **composed-index** PROJECT.md template from `operations/templates/project-md-composed-index-template.md`
(ADR-060 — the thin ≤50-line wiki-link index, replacing the narrative-table shape). Keep
**Methodology + Status inline** (consumer back-compat per `project-schema.md` §4 / §8 consumer
table); scaffold People / Systems / Milestones / Plans / Workstreams as `[[wiki-link]]` lists
into the `_pmo/` entity pages (Step 2b) and the typed plans — not inline tables. Fill in
all fields from user inputs. Apply conditional logic (the inline Methodology block carries the
toggles):

- **Agile projects:** inline cadence = Scrum; link the Sprint Tracker. Omit the phase-gate line.
- **Waterfall projects:** inline cadence = phase-gate; link the Milestone Tracker. Omit the sprint line.
- **Hybrid projects:** include both cadence lines (Sprint Tracker + Milestone Tracker links).
- **Dual-Framing Co-Managed = Yes:** Include Dual-Framing Bridge section with Waterfall milestone framing. Set frontmatter `dual_framing_enabled: true`.
- **Dual-Framing Co-Managed = No:** Omit Dual-Framing Bridge section entirely.
- **`delivery_approach` is a 2-element array `[A, B]` (Hybrid-Two, per project-schema §6.5):** scaffold the array form verbatim in the frontmatter (e.g. `delivery_approach: [Scrum, Kanban]`) and include one native track structure per constituent (union per `work-organization-mapping-framework.md` §2.5). This is orthogonal to the Dual-Framing Bridge — a Hybrid-Two project may have `dual_framing_enabled: false`.
- **`## Routing Signals` (routing-target registration):** populate one line per Layer-2 category, in Layer-2's own order — **Participants · Project keys · Systems · Terminology**. Each line carries **literal match terms, never `[[wiki-link]]`s**: this section is the routing *match index* that `file-router` Layer 2 (project identification) reads, not an entity record, so a wiki-link slug — a token no inbound document carries — scores nothing. Sources: Participants ← Key Stakeholders + any additional stakeholders; Project keys ← Project Name, plus the Jira key and Confluence space when supplied; Systems ← Known systems involved + Implementation Partner; Terminology ← the Project terminology Optional Input. A category with no supplied value is written as `[ASSUMPTION – CONFIRM]` with a proposed value — never left bare, never silently omitted.

Set `last_synced_with_confluence: [today's date]` and `status: ACTIVE`.

**Born NODE frontmatter (top of the composed-index template)** — the node axis, NOT the entity
record. The template opens with the 7-field node block — `type: project-page`, `managed_by:
project-initiator`, `domain: managed`, `folder: _project-root`, `lifecycle_state: emerging`,
`trust_category: controlled-truth`, `created_date` — per `frontmatter-schema.md` § Classification/Trust
and the `agent-processing-contracts.md` Skill-6 contract. Six values are fixed (carried verbatim from
the template); fill `created_date` with today's date. `folder: _project-root` is the NON-BIN SENTINEL
(ADR-139) — PROJECT.md sits at the project ROOT, in no bin, and `folder` is a NOT-NULL core field, so
without this value a newly-scaffolded PROJECT.md is born missing one. `lifecycle_state: emerging` is the
FILE/NODE content-maturity axis; the Project ENTITY's Axis-1 carrier is `status` (project-schema.md §3b,
entity-field-schemas.md V-PRJ-03) — the inline `**Status:**` line, which stays inline and distinct. The
entity-record keys are NOT in this block; they are seeded by the project-schema.md §7 Entity-Seeding
Protocol, not written at scaffold time.

### Step 4: Generate Starter Artifacts

Create empty-but-properly-formatted operational artifacts at the root of `3-Operations/`. Every starter
tracker is born with **Domain-B entity frontmatter** (`type: tracker`, `managed_by: tracker-manager`,
`domain: managed`, `lifecycle_state: created`, `trust_category: controlled-truth`, `created_date`,
`entry_count: 0`) carried from its template per `frontmatter-schema.md` § Domain B. Markdown trackers
embed the block inline; CSV trackers (`RAID_Log.csv`, `Key Terms Glossary.csv`) carry a co-scaffolded
`<file>.csv.meta.yml` sidecar (CSV cannot embed YAML — per `frontmatter-schema.md` § Sidecar File
Specification). The tracker-file *selection* below (Sprint vs Milestone) is file-level, not folder-level —
methodology is carried by the field + coverage map, not the closed folder set.

All governance models get:
1. `[Project]_Daily_Status_Log.md` — From template. Empty carry-forward sections with correct headers.
2. `[Project]_Communications_Tracker.md` — From template. Lifecycle policy included, no entries.
3. `[Project]_Open_Meetings_Tracker.md` — From template. Empty with correct structure.
4. `[Project]_Transcript_Register.md` — From template. Empty register with headers.
5. `[Project]_RAID_Log.csv` — Empty with correct column headers per governance model.
6. `Key Terms Glossary.csv` — Empty with headers: Term, Definition, Context, Source.

Governance-specific additions:
- **Agile/Hybrid:** `[Project]_Sprint_Tracker.md` — Sprint number, goal, capacity, velocity fields
- **Waterfall:** `[Project]_Milestone_Tracker.md` — Phase, milestone, planned date, actual date, status, evidence
- **All with Dual-Framing Co-Managed = Yes:** `[Project]_Dual_Framing_Bridge.md` — Milestone-to-sprint mapping, dual-frame status

Status framework templates:
7. `[Project]_Daily_Status_Update_Framework.md` — Phase-appropriate prompt templates for AM/PM updates
8. `Executive_Status_Report_Prompt.md` — Leadership report prompt template

### Step 5: Update PORTFOLIO.md

Read `projects/_config/PORTFOLIO.md`. Add the new project:

1. Increment `Active Projects` count
2. Add row to Portfolio Health Summary table with initial health = 🟢 GREEN
3. Add project detail section with:
   - Summary from user input or attached docs
   - Phase timeline (from input or `ASSUMPTION – CONFIRM`)
   - Health indicators initialized to 🟢 (no evidence of issues yet)
   - Top Risks = "None identified — project in onboarding"
4. Update Cross-Project Dependencies section if any shared stakeholders or systems detected

### Step 5a: Post-Creation Validation

After updating PORTFOLIO.md (Step 5), validate the write before proceeding:

1. **Re-read PORTFOLIO.md** and locate the new project entry
2. **Field completeness check:** Verify all required fields are populated:
   - Project name matches folder name
   - Health indicators present (initialized to 🟢)
   - Phase timeline present
   - Key contacts present (at minimum: Sponsor, PM, Tech Lead)
   - Governance model recorded
   - Go-live target date recorded with day-of-week validation
3. **Cross-reference with PROJECT.md:** Compare PORTFOLIO.md entry against PROJECT.md for consistency:
   - Go-live date matches
   - Phase description matches
   - Stakeholder names match
   - Governance model matches
4. **If discrepancies found:** Auto-correct the PORTFOLIO.md entry and present the diff to the user: "Fixed: PORTFOLIO.md listed go-live as [X] but PROJECT.md says [Y]. Updated to match PROJECT.md."
5. **If PORTFOLIO.md was not updated** (e.g., write failed or was skipped): Flag as critical: "⚠️ PORTFOLIO.md does not contain an entry for [Project Name]. This must be resolved before proceeding."
6. **Record validation result** in the Step 8 summary as: "Portfolio Updated ✓ — [N] fields verified, [M] corrections applied" or "⚠️ Portfolio Update Failed — manual intervention required."

### Step 5b: Routing-Target Registration Check

A newly scaffolded project must be resolvable as a **routing destination**. `file-router` Layer 2
(project identification) enumerates the active project set at run time and scores each project's
`PROJECT.md` — there is no separate registry to write to, so registration is by construction and
this step **verifies** that construction rather than performing a second write.

1. **Assert the by-construction registration.** `projects/[Project]/PROJECT.md` exists, its inline
   `**Status:**` line reads `ACTIVE`, and the project name is non-empty. These are the three
   properties Layer-2 enumeration depends on. On failure, **halt and surface** — a project the
   enumerator cannot see is not scaffolded, and no later step repairs it.
2. **Score the scaffolded record against Layer 2's four categories**, reading `## Routing Signals`
   only. A category counts as **populated** when it carries at least one literal term. A bare blank
   and an `[ASSUMPTION – CONFIRM]` placeholder both count as **unpopulated** — so the verdict cannot
   be gamed by a placeholder standing in for a term.
3. **Record the verdict** — `Routing target registered ✓ — N of 4 Layer-2 signal categories
   populated (CHEAP · confidence: HIGH)` — and carry it into the Step 8 summary.
4. **Degrade, never block.** `N < 4` is surfaced as `[ASSUMPTION – CONFIRM]` naming each unpopulated
   category and proposing a value drawn from the Required / Optional Inputs. It does **not** halt the
   scaffold: an under-populated routing record still resolves, only at lower confidence. That is a
   quality signal, not a scaffold failure.

### Step 6: Generate User Setup Checklist

Produce a checklist of actions the user must take in parallel systems. This is NOT optional —
it ensures the PMO workspace stays in sync with team tools.

**For Agile / Hybrid:**
- [ ] Verify Confluence space `[key]` exists and is accessible
- [ ] Create project overview page in Confluence (or verify existing)
- [ ] Create FDD folder in Confluence space
- [ ] Verify Jira project `[key]` board is accessible
- [ ] Configure Jira board filters for this project's sprint tracking
- [ ] Set up Google Drive transcript folder (or verify Sembly routing)
- [ ] Invite team members to Confluence space
- [ ] Upload initial documents to appropriate Confluence folders

**For the Waterfall (Sponsor) track:**
- [ ] Create SharePoint project folder (or verify existing)
- [ ] Create milestone tracker in Smartsheet (or verify existing)
- [ ] Set up Google Drive transcript folder (or verify Sembly routing)
- [ ] Share SharePoint folder with project team
- [ ] Upload initial documents to SharePoint

**For Hybrid (both):**
- All Agile items above, PLUS:
- [ ] Create SharePoint folder for the sponsor deliverables
- [ ] Verify Smartsheet milestone tracker accessible
- [ ] Confirm the reporting cadence with the sponsor stakeholder

**MCP Connector Configuration:**
- [ ] Verify Jira MCP connector has access to `[project key]` (if Agile/Hybrid)
- [ ] Verify Confluence MCP connector has access to `[space key]`
- [ ] (Optional) Connect Google Drive MCP for automated transcript ingestion

### Step 7: Recommended Next Steps

Produce an ordered list of what to do after scaffold creation:

1. Complete User Setup Checklist above
2. Upload any initial artifacts (SOW, charter, requirements) — File Router will classify them
3. Schedule project kickoff (if not already scheduled)
4. Run first PPM Agent processing cycle with any available transcripts
5. Review and customize the Daily Status Update Framework for this project's meeting cadence
6. Verify PORTFOLIO.md reflects the new project accurately

### Step 8: Present Summary

Present the user with:
1. Folder structure created (tree view)
2. Files generated (list with purposes)
3. PORTFOLIO.md changes made
4. User Setup Checklist (actionable)
5. Recommended next steps
6. Any `ASSUMPTION – CONFIRM` items that need verification
7. `_pmo/` shared-entity store: bootstrapped (if first project) or linked; entities linked by id; any names routed to the Person clarification queue (Step 2b)
8. Routing-target registration verdict from Step 5b — `Routing target registered ✓ — N of 4 Layer-2 signal categories populated` — naming any unpopulated category and its proposed value
9. Bin orientation cards: 11 copied — or the count copied, naming any that failed (Step 2c)

---

# Mode B: Project Closure

## Purpose

Close out a completed project cleanly: finalize all operational artifacts, produce closure
documentation, archive the project folder, and update the portfolio. After Mode B completes,
the project is read-only reference material with a complete audit trail.

## Required Inputs

| Input | Description | Example |
|-------|------------|---------|
| Project Name | Which project to close (must match an existing project folder) | [PROJECT_KEY] Implementation |
| Closure Reason | Why the project is closing | Go-live complete, hypercare ended |

### Optional Inputs

- Lessons learned notes (from retro, post-mortem, or user input)
- Final status report or executive summary
- List of items to transfer to another project
- Stakeholder sign-off confirmation

## Execution Steps

### Step B1: Read Project State

1. Read the project's `PROJECT.md` — confirm status is `ACTIVE` or `CLOSING`
2. Read `3-Operations/` trackers: Daily Status Log, RAID Log, Communications Tracker,
   Open Meetings Tracker, Transcript Register
3. Inventory the **closed bin set** (`1-Governance/` · `2-Delivery/` · `3-Operations/` · `4-Evidence/` · `5-Reference/`) **and the two transient underscore areas** — `_inbox/`, **including `_inbox/_unsorted/`**, and `_generated/` — for content; note which have artifacts vs. empty. `_inbox/_unsorted/` is named explicitly because it is the population the Step B2 unsorted-hold reconcile and the Step B5 precondition operate on; an inventory that omits it cannot feed them.
4. Read `PORTFOLIO.md` — confirm project is listed as active

If PROJECT.md status is already `CLOSED`, stop and notify user: "This project is already
marked CLOSED. Do you want to re-run closure (e.g., to regenerate the closure summary)?"

#### Step B1a: Closure-Entry Dormancy Hook

While reading project state (Step B1 already reads every tracker), compute the **same dormancy
signal** the `weekly-status-rollup` §7.6 Portfolio Dormancy Sweep uses — the most-recent
substantive modification across {Daily Status Log entries, any `04-PMO-Operations/` tracker
update, any `05-Transcripts/` arrival}, aged as `today − last-artifact-activity-date` in
business days (carries `[INFERRED: today − last-activity-date]`; no codified business-day
primitive yet).

- **If the project is over the `10 business days` dormancy window** at closure, surface it in
  the Step B3 Closure Summary's **Outcome Summary** section as the **reason context** —
  "project dormant N business days prior to closure [INFERRED: today − last-activity-date]" —
  so the closure record states *why* the project was inactive going in.
- **Detector / executor split (de-registration):** `weekly-status-rollup` §7.6 is the
  **detector** that emits the dormancy disposition prompt (proceed / shelve / close); Mode B is
  where the **close** disposition is **executed** (the Step B6 PORTFOLIO.md de-registration that
  drops the project from the active list). A dormancy prompt's `close` option routes here; this
  hook does **not** itself re-decide the disposition — it carries the detected dormancy into the
  closure record and lets Step B6 perform the de-registration.
- **Coverage-gap honesty:** if no tracker baseline exists (a project closed almost immediately
  after initiation), record `dormancy: not assessable — no tracker baseline`; never read "no
  trackers" as "dormant."

This hook is read-only signal computation — it adds reason context, it does not change Mode B's
disposition or archival logic. It is a decision-class surfacing; carry the reversibility tier
per § Reversibility Discipline (the reason-context note is CHEAP).

### Step B2: Finalize Open Items

Review all operational trackers and produce a disposition for every open item:

**RAID Log:**
- Every open Risk/Assumption/Issue/Dependency gets a final disposition:
  - `CLOSED – Resolved`: Evidence of resolution cited
  - `CLOSED – Accepted`: Risk accepted, no further mitigation
  - `CLOSED – Transferred`: Moved to another project (specify which)
  - `CLOSED – Superseded`: No longer relevant due to scope/timeline change
- Produce the updated RAID Log with all items closed and disposition noted

**Daily Status Log:**
- Every carry-forward item gets a final disposition:
  - Blockers: resolved or accepted
  - Actions: completed or transferred
  - Decisions: confirmed or deferred
  - Retest queue: cleared or waived
- Clear all carry-forward sections

**Communications Tracker:**
- All ACTIVE messages: close or archive with final status
- All CORE messages: archive
- Note any permanent-reference items that should survive closure

**Open Meetings Tracker:**
- All scheduled meetings: cancel or mark complete
- Note any recurring meetings that need manual cancellation in external systems

**Transcript Register:**
- All UNASSIGNED transcripts: flag for user decision (process now or close unprocessed)
- All PROCESSING transcripts: complete or close with note

**Unsorted Hold (`_inbox/_unsorted/`):**

This is the set of files `file-router` **could not confidently classify** and held for operator review. Archiving it undispositioned is the silent swallow this surface exists to prevent.

1. **Enumerate the directory:** every file in `_inbox/_unsorted/` **except `_queue.md` itself**. `_queue.md` is the hold's register, not a held item, and never counts as a held file.
2. **Reconcile against `_queue.md`, and take the reconciled union as THE POPULATION.** **Population = (a) the files enumerated in item 1, PLUS (b) every `_queue.md` row with no file on disk.** A file on disk with no queue row, and a queue row with no file on disk, are each recorded as an explicit **divergence row** — never resolved silently, and never dropped from the population because the register disagrees with the directory. **The directory alone is NOT the population.** A row-without-file is invisible to a files-only enumeration, so defining the population as "files on disk" is precisely how a register entry naming a missing item reaches the archive unexamined. The hold is **empty** only when *both* limbs are empty — a directory holding only `_queue.md` is empty only if `_queue.md` also lists no rows.
3. **Assign every *file-bearing* population member exactly one disposition** from the closed set: `CLASSIFIED` · `TRANSFERRED` · `DISCARDED` · `ARCHIVED-AS-UNSORTED`. A **row-without-file takes no disposition** — there is no file to classify, transfer, discard or archive — but it **remains in the population** and is carried as its **divergence row**, which must be surfaced and explicitly acknowledged before the archive move. Dropping it because it cannot take a disposition is the silent swallow this surface exists to prevent; the closed 4-set stays closed, and the divergence row is how a member that no disposition fits still gets seen.
4. `ARCHIVED-AS-UNSORTED` is the **default** — it preserves today's outcome. It is applied only as a **stated choice**, never as a silent fallback, and it is what lets closure complete unattended.
5. Reversibility: `TRANSFERRED` / `DISCARDED` = **EXPENSIVE · confidence: HIGH**; `ARCHIVED-AS-UNSORTED` = **IRREVERSIBLE · confidence: HIGH** (it rides the Step B5 archive move).

### Step B3: Produce Project Closure Summary

Generate `[Project]_Closure_Summary.md` in the project's `1-Governance/` folder:

```markdown
# Project Closure Summary — [Project Name]

**Closure Date:** [Date] ([Day-of-week])
**Closure Reason:** [From input]
**Project Duration:** [Start date] to [Closure date]
**Final Status:** CLOSED

## Project Overview
[Brief description from PROJECT.md]

## Outcome Summary
- **Planned Go-Live:** [Original date]
- **Actual Go-Live:** [Actual date or N/A]
- **Scope Delivered:** [Summary of what was delivered]
- **Scope Deferred:** [Anything cut or deferred, with rationale]

## Key Metrics
- **Total Transcripts Processed:** [Count from Transcript Register]
- **Total RAID Items:** [Count] (Risks: [n], Assumptions: [n], Issues: [n], Dependencies: [n])
- **Communications Sent:** [Count from Comms Tracker]
- **Meetings Tracked:** [Count from Meetings Tracker]

## Final RAID Disposition
| Type | Total | Resolved | Accepted | Transferred | Superseded |
|------|-------|----------|----------|-------------|-----------|
| Risks | | | | | |
| Assumptions | | | | | |
| Issues | | | | | |
| Dependencies | | | | | |

## Unsorted Hold Disposition
| Item | `_queue.md` row (or divergence note) | Disposition | Reversibility |
|------|---------------------------------------|-------------|---------------|
| | | | |

*Population = the Step B2 **reconciled union**: every file in `_inbox/_unsorted/` except `_queue.md`, **plus every `_queue.md` row with no file on disk**. A file-bearing member carries one of the closed 4-set dispositions; a **row-without-file carries its divergence note in the `Disposition` column and takes no disposition** — it is listed, never omitted. An empty population — **both** limbs empty — is recorded as `Unsorted hold: empty — no items held` and the table is omitted.*

## Items Transferred
[Table: Item, Type, Transferred To, Context]

## Lessons Learned
[From user input or extracted from project artifacts]
- What went well
- What could improve
- Recommendations for future projects

## Stakeholder Sign-Off
[List stakeholders and sign-off status — from user input or ASSUMPTION – CONFIRM]

## Archive Location
projects/Archive/[Project]/
```

### Step B4: Update PROJECT.md

Update the project's `PROJECT.md`:
1. Set `status: CLOSED`
2. Add `closure_date: [today]`
3. Add `closure_reason: [from input]`
4. Add `archive_location: projects/Archive/[Project]/`

### Step B5: Move Project to Archive

**Precondition — Unsorted-Hold Reconcile.** Every member of the Step B2 **reconciled union**
(files on disk **plus** `_queue.md` rows with no file) is **accounted for** before the archive move:
a file-bearing member by one of the 

…(truncated)