Project Initiator

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.

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). 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) 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).

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 — 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):

   ^[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.

_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

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:

# 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)