feat: add research-grounded technical project management skill (#468)

* feat: add research-grounded technical project management skill * test: retain isolated project coordination regression evidence
2026-09-11 19:47:12 +03:00 · 2026-09-04 23:56:40 -04:00
parent 3d54d7b68b
commit 22d141de75
47 changed files with 2030 additions and 1 deletions
@@ -1238,6 +1238,15 @@
      "strict": false,
      "description": "Create and review technical documentation, including READMEs, agent-facing instructions, API references, and CLI help. Use when documentation must help someone complete real work. Do not use for marketing copy, brand messaging, or long-form editorial content."
    },
    {
      "name": "technical-project-management",
      "source": "./",
      "skills": [
        "./technical-project-management"
      ],
      "strict": false,
      "description": "Manage technical projects from initiation through delivery and closure: choose and tailor predictive, iterative, Scrum, flow-based, or hybrid approaches; coordinate teams and vendors; track milestones, risks, issues, dependencies, forecasts, scope changes, and recovery. Use when a team has no project manager, a TPM needs decision-ready analysis, a project is slipping, or commitments and handoffs need coordination. Adapt depth to the user's expertise. Do not use for a standalone coding task, product discovery or strategy, only writing an implementation plan, only diagnosing Kanban flow, operating a ticket tool, incident command, or a release go/no-go decision; route those to specialists."
    },
    {
      "name": "technology-radar",
      "source": "./",
@@ -155,6 +155,7 @@
    "./systematic-debugging",
    "./tailscale",
    "./technical-documentation",
    "./technical-project-management",
    "./technology-radar",
    "./telemetry",
    "./tempest",
@@ -563,6 +563,10 @@ Self-hosted Tailscale/Headscale VPN ecosystem. Seven sub-skills covering Headsca
 Make documentation useful at the moment someone needs to install, operate, extend, or troubleshoot a system.
 ### [technical-project-management](technical-project-management/SKILL.md)
 Manage technical projects from initiation through closure: choose and tailor delivery approaches, coordinate teams and vendors, maintain credible forecasts, handle scope changes, recover troubled projects, and hand off operations. Adapts to teams without a PM and experienced TPMs. Ships a research source ledger, four real-world cases, focused references, seven templates, a tested read-only schedule calculator, and output-quality evals. Routes detailed planning, Kanban, product choices, and release mechanics to their specialists.
 ### [technology-radar](technology-radar/SKILL.md)
 Turn technology preferences and architecture-governance choices into explicit, reviewable decisions with owners, evidence, and a proportionate adoption posture.
@@ -62,6 +62,11 @@ sequencing, risk, and verification.
  plan and its execution. Route to [bmad](../bmad/SKILL.md). This skill produces a
  delivery plan; bmad owns the protocol that runs intent-to-delivery work end to end.
 For ongoing milestone reviews, forecast changes, sponsor decisions, and project
 closure after planning, route to
 [technical-project-management](../technical-project-management/SKILL.md).
 Keep detailed work breakdown and dependency-plan maintenance here.
 ## Entry gate: prerequisite approval
 Before any planning work begins, verify that the input requirement or
@@ -73,6 +73,16 @@
        "Decision owner is a role with authority to resolve the dispute.",
        "Does not assign the API contract to either team unilaterally."
      ]
    },
    {
      "id": "route-ongoing-project-control",
      "prompt": "Our approved implementation plan is finished. Help run weekly milestone reviews, handle vendor slips and scope changes, and prepare sponsor recovery decisions.",
      "expected_output": "Routes ongoing project control to technical-project-management while preserving detailed planning ownership.",
      "assertions": [
        "Routes recurring milestone, change and recovery management to technical-project-management.",
        "Does not reframe the whole request as writing another implementation plan.",
        "Preserves prerequisite approval for detailed implementation planning."
      ]
    }
  ]
 }
@@ -123,6 +123,14 @@ If you're new to Kanban or need a refresher, here's the compressed model:
 **Velocity as a proxy for productivity.** Velocity measures output, not outcomes. It is easily gamed, systematically over-optimistic (it ignores waiting time), and creates perverse incentives. Replace with cycle time and throughput trends. See `references/flow-metrics.md`.
 ## When not to use
 For ongoing project commitments, vendor handoffs, scope-change decisions, schedule
 recovery, or project closure, route to
 [technical-project-management](../technical-project-management/SKILL.md).
 Keep board policies, WIP limits, service expectations, and flow diagnosis here.
 A project delay alone is not evidence that the board needs redesign.
 ## How I Consult
 **I push back on premature solutions.** Before any board configuration or policy recommendation, I need to understand your team structure, demand profile, current pain, and organizational constraints.
@@ -51,6 +51,16 @@
        "Links concrete artifacts to validation evidence",
        "States unresolved risks and reproducible next steps"
      ]
    },
    {
      "id": "route-ongoing-project-control",
      "prompt": "Our flow policies work well. I need to manage an external vendor deadline, project scope changes, sponsor decisions and project closure. Should we redesign the board?",
      "expected_output": "Routes project management to technical-project-management without unnecessary flow redesign.",
      "assertions": [
        "Routes project commitments and closure to technical-project-management.",
        "Keeps detailed flow diagnosis within kanban-guru if needed.",
        "Does not prescribe board changes without evidence of a flow problem."
      ]
    }
  ]
 }
@@ -139,6 +139,7 @@
 - [systematic-debugging](systematic-debugging/SKILL.md): Diagnose root causes with a four-phase debugging protocol. Use for ANY technical issue — test failures, production bugs, unexpected behavior, performance problems, build failures, or integration issues. ESPECIALLY when under time pressure, when "one quick fix" seems obvious, or when previous fix attempts have failed. Do not use this skill for unrelated requests; route to the nearest named specialist.
 - [tailscale](tailscale/SKILL.md): Deploy and manage the self-hosted Tailscale/Headscale ecosystem: a Headscale control server, tailscale clients, ACL policies, node lifecycle, subnet routing, DERP relays, and backup/migration. Use when the user mentions Tailscale, Headscale, tailnet, mesh VPN, WireGuard mesh, or self-hosted VPN infrastructure. Do not use this skill for unrelated requests; route to the nearest named specialist.
 - [technical-documentation](technical-documentation/SKILL.md): Create and review technical documentation, including READMEs, agent-facing instructions, API references, and CLI help. Use when documentation must help someone complete real work. Do not use for marketing copy, brand messaging, or long-form editorial content.
 - [technical-project-management](technical-project-management/SKILL.md): Manage technical projects from initiation through delivery and closure: choose and tailor predictive, iterative, Scrum, flow-based, or hybrid approaches; coordinate teams and vendors; track milestones, risks, issues, dependencies, forecasts, scope changes, and recovery. Use when a team has no project manager, a TPM needs decision-ready analysis, a project is slipping, or commitments and handoffs need coordination. Adapt depth to the user's expertise. Do not use for a standalone coding task, product discovery or strategy, only writing an implementation plan, only diagnosing Kanban flow, operating a ticket tool, incident command, or a release go/no-go decision; route those to specialists.
 - [technology-radar](technology-radar/SKILL.md): Build and maintain technology radars for adoption, trial, assessment, and hold decisions, and choose proportionate architecture-governance paths for technology portfolios. Use when governing technology choices, build-versus-buy decisions, architecture standards, exceptions, or engineering portfolio risk. Do not use for enterprise capability or target-state architecture, writing ADRs, implementing systems, security engineering, or operational incident/runbook work.
 - [telemetry](telemetry/SKILL.md): Operate the observability stack that deploys as one unit: Prometheus scrape configuration, recording and alerting rules, relabeling, retention, and high availability; OpenTelemetry Collector pipelines (receivers, processors, exporters, sampling, trace/span correlation); and Loki ingest, LogQL, retention, and label design — with a bundled read-only telemetry-check script for Prometheus rule sanity and scrape-target reachability. Use when running, tuning, or troubleshooting a Prometheus, OpenTelemetry Collector, or Loki deployment, or reviewing the collection/ingest/retention layer, including bounded PromQL and LogQL query construction, semantic review, and no-data diagnosis. Do not use for observability strategy, SLI/SLO design, or paging policy (that is platform-engineering), Grafana dashboards, panels, and Grafana-side alerting (that is grafana), or Tempo/tracing operations, which remain deferred to a future named-tool skill.
 - [tempest](tempest/SKILL.md): Query hyper-local weather from a WeatherFlow Tempest station over its REST API and the hub's local UDP broadcast: current conditions, forecast, historical observations, and real-time decoded datagrams (obs_st, rapid_wind, evt_precip, evt_strike, hub_status). Use when the user asks about weather, temperature, rain, wind, humidity, or forecast data from their own Tempest/WeatherFlow station, or wants to parse the hub's UDP port 50222 broadcast. Do not use this skill for generic or city forecasts without a Tempest station (public weather services serve those), for Shakespeare's play The Tempest or other literature questions, or for weather hardware from other vendors - the REST endpoints require a personal-use token and the UDP broadcast only exists on a Tempest hub's LAN.
@@ -86,7 +86,7 @@ Executive narrative, team view, external/customer view — each tailored.
 ## When Not to Use
 - **For tactical prioritization mechanics** (RICE scores, MoSCoW buckets, Kano categorization, OST trees): route to `product-methodology` or `product-strategy`. This skill references these frameworks only to describe *where* they fit, never to re-explain formulas or mechanics.
- **For project scheduling, Gantt charts, or milestone tracking:** this skill produces outcome roadmaps, not project plans.
+- **For project scheduling, Gantt charts, or milestone tracking:** route to [technical-project-management](../technical-project-management/SKILL.md) for ongoing project control; use [implementation-planning](../implementation-planning/SKILL.md) for detailed planning of approved work. This skill owns outcome roadmaps.
 - **For delivery-flow management:** route to `kanban-guru`.
 - **For corporate capital allocation and M&A portfolio decisions:** route to `strategy-frameworks`.
 - **For shaping a single bet** (setting its appetite, narrowing it into a bounded
@@ -61,6 +61,16 @@
        "Bet owner desire labeled as opinion, not evidence.",
        "Revisit criteria defined."
      ]
    },
    {
      "id": "route-ongoing-project-control",
      "prompt": "Portfolio priorities are agreed. We need weekly milestone tracking, schedule recovery and a project scope-change decision for the selected migration.",
      "expected_output": "Routes ongoing project control to technical-project-management instead of changing the outcome roadmap.",
      "assertions": [
        "Routes ongoing milestone and recovery work to technical-project-management.",
        "Does not substitute a Now/Next/Later roadmap for the requested project control.",
        "Keeps detailed approved work breakdown with implementation-planning."
      ]
    }
  ]
 }
@@ -99,6 +99,7 @@ Each skill's `description` field is the canonical routing contract. This conveni
 | "remote system administration", "remote administration", "remote SSH", "SSH administration", "Ansible administration", "Paramiko automation", "remote Linux", "remote FreeBSD", "remote NetBSD", "remote OpenBSD", "remote macOS", "remote service", "remote firewall", "remote package update", "fleet administration", "fleet rollout", "remote launchctl", "remote rcctl", "remote systemctl" | [remote-systems-administration](../remote-systems-administration/SKILL.md) |
 | "resilience", "recovery", "graceful degradation", "disaster recovery", "DR plan", "game day", "restore test", "failover drill", "RTO", "RPO", "recovery plan", "resilience plan", "data integrity after restore", "recovery exercise", "follow-up work ledger", "recovery communication", "dependency loss", "circuit breaker resilience", "degradation path", "feature shedding" | [resilience-and-recovery](../resilience-and-recovery/SKILL.md) |
 | "restic", "restic backup", "restic repository", "restic restore", "restic prune", "restic forget", "restic check", "restic snapshots", "encrypted backup", "backup retention", "restore drill", "backup integrity", "repository lock", "S3 backup", "SFTP backup" | [restic](../restic/SKILL.md) |
 | "technical project management", "TPM", "no project manager", "project recovery", "milestone tracking", "scope change", "vendor handoff", "project closure", "sponsor decision" | [technical-project-management](../technical-project-management/SKILL.md) |
 | "technical-documentation", "technical documentation" | [technical-documentation](../technical-documentation/SKILL.md) |
 | "secure software engineering", "build securely", "secure by design", "security requirements", "security acceptance criteria", "threat model this design", "secure code review", "secure defaults", "authorization design", "multi-tenant isolation", "tenant trust boundary", "control-plane security", "application-plane security", "tenant identity propagation", "support impersonation security", "tenant backup security", "tenant export security", "tenant deletion security", "noisy neighbor security", "resource exhaustion tenant", "release evidence", "SBOM", "software supply chain", "AI security", "LLM security", "prompt injection", "tool authorization", "RAG security" | [secure-software-engineering](../secure-software-engineering/SKILL.md) |
 | "security-audit-methodology", "security audit methodology" | [security-audit-methodology](../security-audit-methodology/SKILL.md) |
@@ -0,0 +1,52 @@
 # Technical Project Management
 Keep technical projects moving with credible commitments, clear decisions, and useful evidence.
 ## Why Install This Skill
 A team can have good engineers and a busy board while still missing dependencies,
 hiding schedule risk, or leaving decisions unresolved. This skill helps your agent
 coordinate the work from project kickoff through acceptance and operational handoff.
 It selects an approach that fits your constraints instead of imposing one framework.
 Teams without a project manager get a lightweight way to organize ownership and
 next steps. Experienced TPMs get concise analysis, recovery options, and decision
 briefs without introductory lessons. Research references and real cases explain
 where practices help and where their assumptions break down.
 ## What You Get
 | Contents | What they provide |
 |---|---|
 | `SKILL.md` | Focused entry point and connections to specialist skills |
 | `references/` | Method selection, predictive/adaptive/hybrid delivery, control, forecasting, recovery, closure, source ledger, and four real cases |
 | `templates/` | Seven adaptable project records and a worked schedule input |
 | `scripts/` | Read-only dependency schedule analysis with resource-conflict warnings and tests |
 | `evals/` | Realistic quality scenarios covering team and expert use |
 ## Quick Start
 Ask: "We have three teams, a fixed launch date, and a vendor slipping. Help me
 assess the impact and prepare a decision for our sponsor."
 For a schedule calculation, from this directory:
 ```sh
 python3 scripts/schedule.py --input templates/schedule-example.json --json
 ```
 The example returns a finish at working day 6, one day beyond its deadline, and a
 shared-resource conflict. It does not claim those earliest dates are achievable.
 ## Triggers
 - Starting or inheriting a technical project, including teams without a PM.
 - Choosing a delivery approach or coordinating teams and suppliers.
 - Reviewing milestones, forecasts, scope changes, or troubled-project recovery.
 - Preparing a sponsor decision or closing and handing off a project.
 ## Requirements
 No service, API key, or runtime is needed for the guidance and templates. The
 optional calculator and its tests require Python 3.10+ with the standard library.
 Jira or Linear operations use the separate tool skills and their own credentials.
@@ -0,0 +1,136 @@
 ---
 name: technical-project-management
 description: >-
  Manage technical projects from initiation through delivery and closure: choose
  and tailor predictive, iterative, Scrum, flow-based, or hybrid approaches;
  coordinate teams and vendors; track milestones, risks, issues, dependencies,
  forecasts, scope changes, and recovery. Use when a team has no project manager,
  a TPM needs decision-ready analysis, a project is slipping, or commitments and
  handoffs need coordination. Adapt depth to the user's expertise. Do not use for
  a standalone coding task, product discovery or strategy, only writing an
  implementation plan, only diagnosing Kanban flow, operating a ticket tool,
  incident command, or a release go/no-go decision; route those to specialists.
 license: MIT
 compatibility: >-
  Host-neutral methodology and Markdown templates. Optional read-only schedule
  analysis requires Python 3.10+ standard library; no credentials or network.
 ---
 # Technical Project Management
 Help a team make and maintain credible delivery commitments. Start at the user's
 current decision; do not restart a healthy project or impose a new methodology.
 ## First move
 Read existing project artifacts before asking questions. Identify the outcome,
 current phase, immediate decision, decision-maker, constraints, and evidence gaps.
 Infer experience from the request and artifacts; ask about preference only if it
 matters. For teams without a PM, provide a small usable working system and explain
 unfamiliar concepts in context. For experienced TPMs, lead with the delta, options,
 recommendation, and decision needed; omit introductory lessons.
 ## Operating loop
 1. Establish mandate and authority; separate approved commitments, forecasts,
   assumptions, and unknowns. A diagnostic or options brief can precede approval;
   do not turn it into an approved implementation plan.
 2. Select the smallest adequate management approach. Preserve effective existing
   practices and specify any changed decision rights, cadence, and handoffs.
 3. Reuse the implementation plan and maintain milestones, dependency commitments,
   remaining work, resource availability, risks, issues, and decisions.
 4. Compare evidence with the baseline and tolerances. Investigate contradictions;
   missing evidence means unknown, not green. Surface forecast changes immediately
   when material; do not wait for a scheduled report.
 5. Present feasible options when scope, capacity, cost, or dates conflict. Keep the
   baseline history; an authorized change is not permission to hide prior variance.
 6. Close only on acceptance and explicit residual ownership. Distinguish project
   closure, release readiness, service operation, and later benefit realization.
 ## Reference routing
 Read only what the current task requires. Each reference includes applicability,
 procedures, failure signals, and an observable exit.
 | Situation | Read |
 |---|---|
 | New or inherited project, no PM, expert collaboration | [Engagement and initiation](references/engagement-and-initiation.md) |
 | Choosing or questioning a methodology | [Method selection](references/method-selection.md) |
 | Predictive planning, stages, tolerances, fixed constraints | [Predictive and stage governance](references/predictive-and-stages.md) |
 | Scrum, iteration, incremental delivery, discovery uncertainty | [Adaptive delivery](references/adaptive-delivery.md) |
 | Flow, shared specialists, critical chain, appetite-based work | [Flow and constrained capacity](references/flow-and-capacity.md) |
 | Mixed methods, cross-team or vendor interfaces | [Hybrid and dependencies](references/hybrid-and-dependencies.md) |
 | Estimates, forecasts, budgets, schedule model | [Forecasting and schedule analysis](references/forecasting.md) |
 | Weekly control, stakeholder disagreement, escalations | [Control and communication](references/control-and-communication.md) |
 | Scope changes, troubled projects, recovery | [Change and recovery](references/change-and-recovery.md) |
 | Acceptance, cancellation, operational handoff | [Closure and transition](references/closure-and-transition.md) |
 | Real examples or transferability checks | [Case studies](references/case-studies.md) |
 | Research provenance, edition, evidence limits | [Source index](references/source-index.md) |
 | Skill purpose, coverage, research decisions | [Research brief](references/research-brief.md) |
 | Validation scope and behavioral evaluation protocol | [Evaluation guide](references/evaluation-guide.md) |
 ## Templates and calculation
 Adapt existing project documents rather than creating parallel sources of truth.
 Use only artifacts that answer a current decision.
 | Need | Artifact |
 |---|---|
 | Establish mandate and working agreements | [Project brief](templates/project-brief.md) |
 | Explain method choice and adaptation | [Approach decision](templates/approach-decision.md) |
 | Maintain milestones and evidence | [Project control record](templates/project-control.md) |
 | Coordinate a supplier or receiving team | [Dependency agreement](templates/dependency-agreement.md) |
 | Report a change and ask for a decision | [Status and decision brief](templates/status-and-decision.md) |
 | Assess scope changes or recovery options | [Change and recovery record](templates/change-and-recovery.md) |
 | Accept, cancel, or transfer ownership | [Closure record](templates/closure-record.md) |
 | Calculate a small dependency network | [Example schedule](templates/schedule-example.json) |
 Run `python3 scripts/schedule.py --input templates/schedule-example.json --json`
 from this skill's directory when dependency arithmetic helps. Read forecasting
 first: the result is an unconstrained earliest schedule, not a commitment or a
 resource-leveled plan. The script only reads input and writes stdout/stderr.
 Run `python3 -m unittest discover -s scripts -p 'test_*.py'` for its tests.
 ## When not to use
 - A coding fix or architecture design: use the applicable engineering skill.
 - Validating needs or choosing product investments: use
  [product-discovery](../product-discovery/SKILL.md) or
  [product-roadmapping-and-portfolio](../product-roadmapping-and-portfolio/SKILL.md).
 - Only decomposing an approved requirement: use
  [implementation-planning](../implementation-planning/SKILL.md).
 - Detailed board, WIP, or service-flow diagnosis: use
  [kanban-guru](../kanban-guru/SKILL.md).
 - Shaping a bounded product bet: use [product-shaping](../product-shaping/SKILL.md).
 - Product-wide decision rights: use
  [product-operations-and-governance](../product-operations-and-governance/SKILL.md).
 - Executive-office support: use
  [chief-of-staff-methodology](../chief-of-staff-methodology/SKILL.md).
 - Release mechanics or launch approval: use
  [release-engineering](../release-engineering/SKILL.md) and
  [production-readiness](../production-readiness/SKILL.md).
 - Live incident command: use
  [site-reliability-engineering](../site-reliability-engineering/SKILL.md).
 - Ticket operations alone: use [jira](../jira/SKILL.md) or
  [linear](../linear/SKILL.md). Use [financial-modeling](../financial-modeling/SKILL.md)
  for financial model construction, and [legal-strategy](../legal-strategy/SKILL.md)
  for contract interpretation.
 ## Authority and completion
 This methodology prepares decisions. It does not invent stakeholder consent,
 assign accepted commitments on someone else's behalf, or approve risk. Updating
 external project systems or sending communications changes external state:
 > Confirm the target, scope, and rollback path before acting. Read-only discovery may proceed without confirmation.
 Apply existing session authorization; do not ask repeatedly for the same scope.
 Destructive actions need an explicit directive. Keep prepared drafts visibly distinct
 from issued communications. Do not monitor people or turn activity counts into
 individual performance judgments.
 Complete a requested management cycle when the artifact or update is delivered,
 claims have evidence or explicit uncertainty, and unresolved decisions have an
 accountable route and next review trigger. Do not imply ongoing monitoring without
 an authorized mechanism. If three diagnostic passes yield no new evidence, stop
 with the missing input and affected decision; do not manufacture certainty.
@@ -0,0 +1,143 @@
 {
  "schema_version": 1,
  "skill_name": "technical-project-management",
  "evals": [
    {
      "id": "no-pm-small-team",
      "prompt": "We are four engineers working part-time on a customer migration. Nobody is a PM. Our launch date is only a sales wish, there is no accepted scope, and we keep forgetting decisions. Help us get organized without adding lots of meetings.",
      "expected_output": "A lightweight initiation brief with actual authority and uncertainty, not an invented committed plan.",
      "assertions": [
        "Distinguishes desired date from an accepted deadline.",
        "Identifies approval and scope gaps without refusing all diagnostic help.",
        "Uses part-time availability rather than four full-time resources.",
        "Proposes a small source of truth and decision cadence, without imposing a PMO."
      ]
    },
    {
      "id": "expert-tpm-vendor-slip",
      "prompt": "I am the TPM. Skip the basics. Baseline integrated acceptance is working day 20. A vendor interface, needed by day 12, is now forecast for day 18; integration takes 10 working days after receipt. Sponsor review is tomorrow. Give me a concise decision brief with options; vendor commitment is unconfirmed.",
      "expected_output": "An expert-paced brief stating day 28 forecast and 8-day variance under the stated sequential assumptions, with feasible options and authority.",
      "assertions": [
        "Computes forecast day 28 and variance of 8 working days.",
        "Keeps vendor forecast distinct from commitment.",
        "Provides options and a sponsor decision rather than a terminology lesson.",
        "Does not claim adding engineers necessarily compresses integration.",
        "Identifies the pre-existing inconsistency: receipt day 12 plus 10 days implies day 22, not baseline day 20."
      ]
    },
    {
      "id": "hybrid-device-project",
      "prompt": "Our device supplier uses phase approvals and has an 8-week lead time. Software uses two-week sprints, and calibration is unproven. The whole device needs certification. Pick a project approach and explain how the teams coordinate.",
      "expected_output": "A justified hybrid with explicit interface and acceptance contracts, not forced synchronization.",
      "assertions": [
        "Separates hardware/procurement governance from software iteration.",
        "Defines an early calibration learning checkpoint.",
        "Does not equate sprint completion or simulator success with certification.",
        "Names provider/receiver acceptance and escalation needs."
      ]
    },
    {
      "id": "misleading-green-status",
      "prompt": "My dashboard is green because 90 percent of tickets are done. End-to-end tests have not run, the remaining scope is unknown, and the sponsor wants a reassuring update. Draft it.",
      "expected_output": "Truthful health assessment and a targeted evidence request with a next decision.",
      "assertions": [
        "Does not issue an unqualified green status.",
        "Separates ticket completion from integrated acceptance.",
        "Identifies remaining-work and test evidence gaps.",
        "Provides recovery or evidence-gathering actions without inventing results."
      ]
    },
    {
      "id": "shared-resource-network",
      "prompt": "Analyze templates/schedule-example.json. Is the deadline achievable? Both build and review-prep require the same exclusive specialist.",
      "expected_output": "Correct dependency calculation and explicit resource-feasibility limitation.",
      "assertions": [
        "Reports unconstrained finish at day 6 and 1-day deadline gap.",
        "Identifies overlapping specialist demand.",
        "Does not present day 6 as a resource-feasible commitment.",
        "Does not call the calculation Monte Carlo or critical-chain scheduling.",
        "Resolves this simple exclusive-resource sequence to earliest day 7, two days late, under the stated assumptions."
      ],
      "files": [
        "templates/schedule-example.json"
      ]
    },
    {
      "id": "change-with-fixed-constraints",
      "prompt": "An approved project has 20 days of remaining work and 20 days available. Sales adds a mandatory 5-day feature and says scope, quality, date and cost cannot move. Draft a change decision; do not contact anyone.",
      "expected_output": "A conflict and conditional options; preserved baseline and no unauthorized communication.",
      "assertions": [
        "States the capacity/constraint conflict.",
        "Presents scope swap, date/capacity alternatives or explicit infeasibility rather than a magical compliant plan.",
        "Keeps current baseline until authorized change.",
        "Produces a draft and does not claim notification or agreement."
      ]
    },
    {
      "id": "research-with-no-history",
      "prompt": "We need an AI extraction system with 99 percent accuracy in six weeks. There is no labeled dataset or delivery history. Give us a P95 completion date.",
      "expected_output": "Declines unsupported precision and substitutes bounded learning/evaluation milestones.",
      "assertions": [
        "Does not invent a P95 date or historical sample.",
        "Identifies missing evaluation data and definition of accuracy.",
        "Proposes a bounded feasibility/evidence checkpoint with an owner.",
        "Distinguishes learning completion from production acceptance."
      ]
    },
    {
      "id": "closure-without-owner",
      "prompt": "The software shipped yesterday. Support has not agreed to own it, three known defects remain, and Finance has not checked supplier invoices. Close the project as successful.",
      "expected_output": "Conditional closure decision with residual obligations and receiving acceptance.",
      "assertions": [
        "Does not declare unconditional closure.",
        "Names support acceptance and financial reconciliation gaps.",
        "Requires disposition and accepted ownership for defects.",
        "Separates deployment from benefit realization."
      ]
    },
    {
      "id": "scrum-accountabilities",
      "prompt": "I coordinate three Scrum teams. Can I assign every developer tasks and require sponsor signoff at every Sprint Review so our project dates are safe? Give a better coordination approach.",
      "expected_output": "Preserves Scrum accountabilities while adding cross-team milestone/decision coordination.",
      "assertions": [
        "Does not give the coordinator unilateral control of Developers delivery plans.",
        "Does not make Sprint Review a mandatory release gate.",
        "Defines shared dependency or integration evidence.",
        "Distinguishes any actual organizational approval obligation from Scrum events."
      ]
    },
    {
      "id": "case-transfer-limits",
      "prompt": "GitHub upgraded more than a thousand MySQL hosts successfully. We have twelve databases; can we copy their rollback plan and promise the same SLO outcome?",
      "expected_output": "Uses the case as coordination evidence with explicit technical and causal limitations.",
      "assertions": [
        "Labels GitHub outcome as self-reported.",
        "Rejects an automatic guarantee based on fleet size.",
        "Requires architecture-specific rollback validation.",
        "Transfers readiness and coordination practices without copying unsupported technical assumptions."
      ]
    },
    {
      "id": "appetite-regulatory-conflict",
      "prompt": "Our team likes Shape Up. We have a legal reporting obligation with mandatory scope in 10 weeks. Can we just stop after a six-week bet if it is unfinished?",
      "expected_output": "Identifies mismatch between discretionary appetite and mandatory obligation; routes formal interpretation.",
      "assertions": [
        "Does not recommend abandoning a mandatory obligation by default.",
        "Separates appetite from feasibility estimate.",
        "Proposes bounded discovery or delivery slices within a governed obligation.",
        "Routes contract/legal interpretation to the appropriate specialist rather than inventing it."
      ]
    },
    {
      "id": "stale-inherited-plan",
      "prompt": "I inherited a project with a red forecast. The sponsor asks me to delete the old baseline and call the new date the original target. We also have no evidence for vendor percent complete. What should I do?",
      "expected_output": "Preserves history and reconstructs evidence for an authorized recovery decision.",
      "assertions": [
        "Does not erase or misrepresent the original baseline.",
        "Separates current forecast from baseline approval.",
        "Requests vendor acceptance/remaining-work evidence.",
        "Offers recovery options with an accountable decision path."
      ]
    }
  ]
 }
@@ -0,0 +1,63 @@
 # Initial sampled behavioral review
 Date: 2026-09-05. Reviewer: authoring assistant. These are actual captured responses,
 not golden answers. Configuration: two fresh Codex subagent contexts, one with the
 skill and one without; each answered the same three prompts. No model override was
 requested. Model version, token use, and exact timing were not captured.
 Candidate: precommit working tree on `codex/technical-project-management`, based on
 `de968df`. Exact per-run content hashes were not captured. This is informal evidence,
 not the repository's versioned runtime provenance or release-gate contract.
 ## Assertion review
 | Case | Baseline | With skill | Evidence in captured outputs |
 |---|---|---|---|
 | expert-tpm-vendor-slip | 5/5 | 5/5 | Both expert responses calculate day 28 and 8-day variance, identify the old day-12-plus-10 inconsistency, keep vendor dates conditional, and give decision options without a primer |
 | no-pm-small-team | 4/4 | 4/4 | Both team responses retain sales date as a target, seek accepted scope/authority, use actual part-time capacity, and propose a lightweight written decision system |
 | shared-resource-network | 5/5 | 5/5 | Both schedule responses distinguish unconstrained day 6 from a feasible serial day 7, show the shared resource, and explain why a second specialist alone does not meet day 5 |
 Outputs are retained in `samples/baseline-expert.md`, `samples/with-skill-expert.md`,
 `samples/baseline-team.md`, `samples/with-skill-team.md`,
 `samples/baseline-schedule.md`, and `samples/with-skill-schedule.md`.
 ## What changed after review
 Both variants passed the original assertions. The expert response's baseline
 consistency check and the resource response's day-7 reasoning were valuable but
 not required by the initial manifest. Added those assertions without changing IDs.
 The captured answers satisfy the strengthened checks too.
 The with-skill team response supplied board columns and one-active-item-per-engineer
 advice without diagnosing flow. The engagement reference now explicitly preserves
 existing boards and routes WIP design to kanban-guru. The forecasting reference now
 includes the small resource-feasible example. The script also gained bounded
 resource-conflict output and a test during the review period. These refinements
 were mechanically checked; the sample is not a rerun of the final revision.
 ## Limits and conclusion
 These three scenarios did not distinguish skill-assisted from baseline quality.
 Both scored 14/14 on the final reviewed assertions. Do not infer general improvement
 or reliability from that result. Each variant used one context across three prompts,
 so prompts were not individually isolated. Grading was not blind or independent,
 and only three of twelve cases were exercised. The remaining cases are authored
 contracts, not demonstrated behavioral passes. CI's fake-adapter run is a harness
 smoke test, not additional model evidence.
 Further evaluation should use individually isolated cases, a blinded reviewer,
 and difficult multi-artifact project records, including contradictory status and
 changing scope across several management cycles. The initial evidence supports
 usable sample outputs and concrete refinements, not a "world-class" certification.
 ## Isolated follow-up on the revised guidance
 A third, fresh context reran only no-pm-small-team against commit `5546fc7`
 without reading assertions or previous outputs. Its actual response and content
 digests are retained as `samples/final-team.md` and
 `samples/final-team-provenance.json`. The response passes the four case assertions
 and preserves the existing board without prescribing a per-person WIP limit,
 addressing the concrete issue from the first sample. No additional management
 instructions were changed after this follow-up. This is one observed regression
 check, not a paired demonstration of improvement or a substitute for the unrun
 cases.
@@ -0,0 +1,13 @@
 Decision needed tomorrow: authorize a provisional day-28 integrated-acceptance forecast and choose whether to fund a recovery investigation. Preserve day 20 as the baseline until an approved change; do not present it as credible on current evidence.
 The interface forecast is day 18, six working days beyond its day-12 need date. Ten working days of integration after receipt gives acceptance no earlier than day 28, eight days beyond baseline. Even receipt on day 12 yields day 22, so the prior dependency plan already contains a two-day inconsistency. Confirm the milestone definitions and calendar; the arithmetic assumes elapsed working-day offsets and that integration includes all acceptance work. Vendor commitment is unconfirmed, so day 28 is conditional, not a committed date.
 | Option | Implication | Evidence needed before commitment |
 |---|---|---|
 | Rebaseline full scope | Provisional acceptance day 28 or later; least execution compression | Written vendor delivery commitment, integration-owner estimate, acceptance coverage |
 | Recover day 20 | Receipt must move to day 10 at the current integration duration, or receipt on day 18 must be paired with integration reduced to two days | Demonstrated acceleration or safe pre-integration against a stable contract; incremental cost and residual risk |
 | Stage delivery | Accept an explicitly independent subset by day 20; defer vendor-dependent scope | Customer/sponsor agreement on useful scope, distinct acceptance criteria, operational consequences |
 Recommendation: plan provisionally for full acceptance on day 28, obtain the vendor commitment urgently, and time-box investigation of staged delivery and pre-integration. Do not promise an eight-day recovery without a validated plan. Sponsor should choose which constraint can move—date, scope, or cost—and name the approver for the resulting baseline change.
 Before tomorrow's review, the vendor owner requests a dated commitment and escalation path; the integration lead validates duration, sequencing, and the day-12/day-20 discrepancy; the TPM records the options, owners, assumptions, and decision. If the vendor cannot commit, show a conditional forecast and outstanding exposure rather than a manufactured confidence range.
@@ -0,0 +1,16 @@
 The day-5 deadline is not achievable with the stated durations, dependencies, and one exclusive specialist. The earliest completion is day 7: two working days late.
 Using elapsed working-day boundaries from time 0:
 | Task | Start | Finish | Constraint |
 |---|---:|---:|---|
 | design | 0 | 2 | None |
 | build | 2 | 5 | After design; specialist |
 | review-prep | 5 | 6 | After design; same exclusive specialist |
 | accept | 6 | 7 | After build and review-prep |
 Review-prep could run before build without changing completion. After design, the specialist must perform four days of work serially; acceptance then takes another day. Thus the resource-constrained duration is 2 + 3 + 1 + 1 = 7 days.
 Even ignoring the resource conflict, the dependency-only critical path is design → build → accept, totaling six days. A second specialist alone therefore improves completion to day 6, still one day late.
 To make day 5 credible, approve and validate changes that remove two elapsed days from the resource-constrained plan. For example, a second qualified specialist plus a one-day reduction in the dependency critical path could suffice. Alternatively, reduce two days from the serial schedule without compromising acceptance. Without such validated scope, duration, or dependency changes, move the deadline to at least day 7. These are deterministic earliest dates; they contain no allowance for uncertainty or resource availability beyond the fixture.
@@ -0,0 +1,21 @@
 Use one shared page and one small task board. Pick one engineer to maintain them for the next two weeks; rotate that role if useful. This is coordination work, not a new management layer.
 Start with a single 30-minute conversation with the person who can approve the migration scope. Agree on the customer outcome, what is included and excluded, how you will know it worked, and who accepts it. Record the sales date as a requested date until you have a feasible plan and the approver accepts it.
 Put these items on the shared page:
 | Item | What to capture |
 |---|---|
 | Outcome and scope | One paragraph, explicit exclusions, acceptance checks |
 | People and capacity | Each engineer's actual available days or hours per week |
 | Milestones | Trial migration, readiness decision, cutover, customer acceptance |
 | Dependencies and risks | Access, data quality, customer availability, blockers and owners |
 | Decisions | Date, decision, reason, decision-maker, affected work |
 Create board columns for Ready, Doing, Blocked, and Done. Each card needs one owner, a small deliverable, and a completion check. Start with discovery tasks wherever uncertainty prevents estimating; don't turn guesses into deadlines. Limit active work to fit your part-time capacity, and make dependencies visible before assigning target dates.
 For the migration itself, include a trial run, reconciliation checks, backup and rollback, a named cutover decision-maker, and support after launch. Use these as readiness conditions rather than treating the requested date as permission to cut over.
 Replace routine status meetings with a twice-weekly async note from each person: completed, next, blocked, capacity changes. Discuss only unresolved decisions, preferably in an existing meeting or a short ad hoc call. The coordinator updates the board and decision log immediately after agreements, so chat history is not your record.
 By the end of the first week, aim for accepted scope, a visible backlog, realistic capacity, and a preliminary date forecast with assumptions. Ask the approver to choose scope or timing tradeoffs if that forecast misses the sales request. Revisit the lightweight process after two weeks and remove anything nobody uses.
@@ -0,0 +1,23 @@
 {
  "git_head": "5546fc7b047a61f36e7f2a9ab4bd5b2332fd4acd",
  "files": [
    {
      "path": "SKILL.md",
      "sha256": "84334ec52a72b1e9c54e78a97fab95fab252de33e6f59747defca187604d053c"
    },
    {
      "path": "references/engagement-and-initiation.md",
      "sha256": "79733a8b988845622db5cb6f5e15e1b29dffa8a7513b31e04c82096dbf5847da"
    },
    {
      "path": "references/method-selection.md",
      "sha256": "cf5724eb6552b2b2e71643c6c849b4f516891f1a63af71e1dda2d656ed2b18f9"
    },
    {
      "path": "references/flow-and-capacity.md",
      "sha256": "776ca07c6a4cb083a6051861490a31b17ecdbff652379076101dc5ba6b176fac"
    }
  ],
  "output": "evals/samples/final-team.md",
  "scope": "Single fresh-context follow-up; informal provenance, not repository release-gate contract"
 }
@@ -0,0 +1,40 @@
 Use one shared project note and your existing task board. For now, label the launch date **“sales target — feasibility and commitment unconfirmed.”** Without accepted scope and actual availability, you do not yet have a reliable delivery forecast.
 I suggest a small milestone-based approach: agree the minimum migration outcome, test the uncertain parts, then plan the next useful slice. Four part-time engineers do not need a full Scrum meeting schedule to fix unclear commitments and lost decisions. This is a proposed working agreement for the team to accept.
 **Copy this into your shared project note:**
 | Field | Starting entry |
 |---|---|
 | Outcome | Move the agreed customer workload and data to the destination, with acceptance criteria still to be agreed. |
 | Included scope | Unknown: identify customers, data, integrations, and migration support included. |
 | Excluded scope | Agree explicitly; list requested improvements that can wait. |
 | Acceptance | Propose evidence for data reconciliation, essential customer workflows, allowable interruption, and support handoff; have the customer/business acceptance owner agree the thresholds. |
 | Date | Sales target; record the requested date, its source, and business reason. No accepted deadline or forecast yet. |
 | Decision authority | Name the person authorized to accept scope and date tradeoffs, and the person authorized to accept the migration result. These may be the same person. |
 | Coordination | Ask one engineer to accept a lightweight coordinator role through the first milestone, with a backup. They maintain this note and surface blockers; they do not acquire authority to approve scope or business risk. |
 | Capacity | Each engineer records sustainable hours for the next two weeks, absences, other obligations, and any specialist work only they can do. Count coordination and review within those hours. |
 | Next decision | Within the next two working days, proposed: scope/date authority approves the minimum scope and evidence needed before a forecast. If they are unavailable, record the decision as blocked. |
 **Make the first milestone “minimum migration scope accepted.”** Its evidence is the approver’s written agreement on what moves, what success means, and what can wait. The coordinator can gather existing requests and open questions asynchronously; do not turn this proposed scope into an implementation commitment before approval. Continue already authorized work within its existing scope.
 After that approval, choose a small representative migration rehearsal if technically appropriate and authorized. Use its results, remaining work, dependencies, and real availability to produce a provisional date range. A rehearsal is evidence for planning, not permission for production cutover. If the sales target cannot fit, the scope/date authority chooses among reducing scope, moving the target, or securing additional suitable capacity.
 **Keep tasks and decisions separate but linked.** Each board task needs an agreed owner, a concrete finish condition, and any blocker or dependency. Preserve your existing board rather than introducing another tracker.
 Use this decision log in the shared note:
 | Date | Decision/question | Status | Decider | Reason and consequence | Linked work | Revisit trigger |
 |---|---|---|---|---|---|---|
 | Today | Is the sales target a commitment? | Open | Scope/date authority, to identify | Scope and capacity are unconfirmed | Scope milestone | Scope accepted and forecast available |
 Mark entries proposed, accepted, or superseded. Capture an accepted decision immediately after the discussion and link the written confirmation. Keep superseded decisions so nobody has to reconstruct why the plan changed.
 **Keep the cadence small:**
 - Once a week, everyone adds three short lines asynchronously: completed evidence, next work within available hours, and blockers or decisions needed.
 - The coordinator updates the next milestone and lists each blocker with the person being asked, the needed response, and when delay becomes consequential.
 - Hold a maximum 20-minute discussion only when an unresolved decision needs conversation; cancel it when the written update is enough. No new daily standup.
 - Surface lost capacity, blocked dependencies, or changes threatening the forecast when discovered, rather than waiting for the weekly update.
 Review this arrangement after two weeks or immediately if it stops producing decisions. Setup is sufficient when the accepted scope, decision authority, real capacity, next milestone, and open decisions are visible. The project itself finishes only when the agreed acceptance evidence is signed off and remaining support work has an accepted owner.
@@ -0,0 +1,17 @@
 **Decision for tomorrow: authorize a recovery investigation and choose which constraint can move. Day 20 is unsupported by the current integration logic.**
 The vendor forecast moved six working days, from needed-by day 12 to day 18. Ten working days after receipt puts integrated acceptance at **day 28, eight days beyond the day-20 baseline**, assuming the interface is usable immediately and those ten days include acceptance. Day 18 is unconfirmed, so day 28 is conditional, not a commitment.
 There is also a pre-existing two-day inconsistency: day 12 + 10 = day 22. Meeting day 20 with unchanged integration requires usable receipt by day 10. Reconcile the baseline logic before attributing the full eight-day variance to this vendor change.
 | Option | Consequence / evidence required |
 |---|---|
 | Retain full scope; move acceptance | Plan around conditional day 28 or later. Confirm vendor handoff, integration capacity, and acceptance duration before committing. Sponsor approval required to change baseline. |
 | Protect day 20 through recovery | Requires receipt by day 10, or eight days of validated overlap/duration reduction against day-18 receipt. Technical lead and vendor must demonstrate feasibility; added people alone do not prove compression. |
 | Deliver a reduced or staged outcome by day 20 | Identify an independently acceptable slice and obtain acceptance-owner approval. Mocks may enable early work but cannot silently replace integrated acceptance. Date feasibility remains unproven. |
 **Recommendation:** retain day 20 as the historical baseline, report the day-28 conditional forecast now, and use full-scope date movement as the planning scenario while testing a genuinely acceptable staged outcome. Do not promise recovery tomorrow without evidence.
 **Before the review:** TPM obtains the vendor's written forecast/commitment distinction, deliverable version, handoff evidence, and next confirmation time; integration lead reconciles the ten-day sequence with the baseline and identifies credible overlap. These are proposed assignments to confirm with the owners. If confirmation is absent tomorrow, explicitly report the missing commitment and request sponsor escalation to the vendor's accountable owner.
 **Sponsor ask:** state whether full scope or day 20 takes priority, authorize the bounded recovery assessment, and name who can approve a scope/date change. Agree the next decision checkpoint tomorrow, tied to vendor confirmation and the integration lead's revised sequence; do not overwrite the baseline while these decisions are pending.
@@ -0,0 +1,20 @@
 **No. With the supplied durations and one exclusive specialist, earliest completion is working-day offset 7—two working days after the deadline of 5.** This assumes uninterrupted specialist availability and no rework.
 I ran the skill's schedule helper against the supplied JSON. Its dependency-only result is finish 6, already one day late. It flags overlapping specialist demand from offsets 2–3: build and review-prep both start after design. The tool detects resource conflicts but does not resolve them.
 A feasible sequence under the stated resource constraint is:
 | Task | Start offset | Finish offset |
 |---|---:|---:|
 | design | 0 | 2 |
 | build | 2 | 5 |
 | review-prep | 5 | 6 |
 | accept | 6 | 7 |
 Reversing build and review-prep also finishes at 7. After design, the specialist must perform 3 + 1 = 4 days of work sequentially, followed by one day of acceptance: **2 + 4 + 1 = 7**. These are elapsed working-day offsets, not inclusive calendar dates.
 The helper reports design, build, and accept as zero-float tasks in its unconstrained model; review-prep's two days of apparent float do not make the specialist conflict disappear. The resource-constrained sequence makes its work part of the completion constraint too.
 To meet offset 5, the plan needs an approved change: reduce elapsed work on this sequence by two days, or validate changed dependencies/capacity that achieve equivalent savings. A second qualified specialist alone permits the original parallel plan but still finishes at 6, one day late. Otherwise move the deadline to at least offset 7, with any contingency justified separately.
 Have the task owners validate durations and the specialist's availability, then have the deadline owner choose a date or scope/capacity tradeoff. Record that decision and recalculate before making a commitment. Day 7 is a deterministic lower bound under these assumptions, not a confidence-rated promise.
@@ -0,0 +1,34 @@
 Use one shared page and your existing work board. You do not need a dedicated PM to make decisions and unfinished work visible.
 Start with this copyable page. Treat the launch date as a **sales target, not an agreed delivery promise** until scope and available time support it.
 | Migration agreement | Current entry |
 |---|---|
 | Outcome | Customer migration; specify the customer, data/services moving, and why |
 | Included / excluded | Not yet accepted; list both before promising a date |
 | Successful completion | Draft: agreed data reconciles, required customer workflows pass, and a named customer representative accepts the result |
 | Launch target | Sales wish; record date, source, and consequence of missing it |
 | Delivery forecast | Unknown until scope, dependencies, and part-time availability are checked |
 | Scope/date authority | Name the person who can approve tradeoffs; currently unconfirmed |
 | Acceptance authority | Name the customer representative who can accept the result; currently unconfirmed |
 | Coordinator | One engineer volunteers to keep this page current; this does not give them scope or architecture authority |
 | Next milestone | Agreed migration scope, acceptance checks, and a capacity-based first forecast |
 For the first pass, each engineer adds their sustainable hours or available work blocks for the next two weeks, absences, and other obligations. Four part-time engineers are not four full-time people. Identify customer access, data samples, and any specialist or vendor dependency that could hold up the work.
 Keep the board to **Ready → Doing → Waiting → Done**. Each item needs an agreed owner, a small concrete result, and a check that proves it is done. Start with one active item per available engineer; show blockers and their next action in Waiting. Do not fill everyone’s calendar with speculative work before the migration scope is accepted.
 Add this decision log underneath the agreement:
 | Date | Question | Decision or pending choice | Who can decide | Reason / evidence | Revisit trigger |
 |---|---|---|---|---|---|
 | Today | What is the migration scope? | Pending: draft included/excluded list | Scope authority—confirm name | Current scope is unaccepted | Before date commitment |
 | Today | Is sales' launch date feasible? | Unknown | Scope/date authority—confirm name | Scope and availability missing | First forecast prepared |
 Record a decision when it happens, with a link to the relevant discussion. A proposed choice remains pending until the right person agrees. Changes to accepted scope should show their date/capacity impact before being accepted.
 Use one weekly asynchronous update: **finished and checked; next result; blocker or decision needed**. Only schedule a short discussion when a written decision is stuck; no daily status meeting is necessary. The coordinator gathers unresolved choices for the person who can decide them.
 For your first week, propose volunteers to draft the scope and acceptance checks, gather availability, and confirm the customer's acceptance contact. Get their agreement to those responsibilities. By the end of that week, review the shared page asynchronously with the scope/date authority: approve the scope, revise it, or explicitly leave the date uncommitted. Then plan one small migration rehearsal with clear checks, recovery steps, and authorization before touching customer production data.
 This setup is enough once everyone can find the accepted scope, next milestone, current blockers, and decisions. Revisit it if work repeatedly waits on the same person or the weekly update fails to surface a material change.
@@ -0,0 +1,53 @@
 # Iterative, incremental, and Scrum delivery
 Use for uncertain requirements, learning through feedback, or a team using Scrum.
 Basis: S02 for Scrum definitions, S05 for incremental development and oversight.
 The project-coordination procedure is original synthesis.
 ## Preserve framework accountabilities
 In Scrum, the Product Owner orders product work, Developers manage their delivery
 plan, and the Scrum Master supports Scrum effectiveness. The project coordinator
 handles cross-boundary commitments without taking over those accountabilities.
 A Sprint Goal is not a guarantee that every selected item will finish. Work that
 misses the Definition of Done is not a completed increment. Sprint Review is not
 an additional release approval gate. These distinctions come from S02.
 ## Manage uncertainty explicitly
 1. Identify the uncertainty that could invalidate the delivery forecast: user
   need, technical feasibility, integration, data quality, or operational fitness.
 2. Define a small learning or delivery outcome with an evaluator and evidence.
   A prototype may retire a risk without being production-ready.
 3. Reserve capacity for validation, integration, rework, and support; avoid a
   capacity plan that assumes every hour produces new scope.
 4. Inspect results with people able to decide the next step. Record what changed
   in the assumption, scope, forecast, or acceptance evidence.
 5. Update the broader milestone view from accepted work and remaining uncertainty.
   Report scope growth separately from throughput so progress is not obscured.
 Do not convert one team's story points into another team's dates or compare people
 by velocity. Use a stable team's relevant delivery history only when item boundaries,
 quality criteria, capacity, and work mix are comparable. A new team needs explicit
 uncertainty and an early calibration checkpoint, not invented historical data.
 ## Boundary cases
 | Situation | Management response |
 |---|---|
 | A deadline is fixed but research may fail | Commit to a learning decision or bounded fallback; do not promise the research result |
 | User feedback is unavailable | Find a legitimate evaluator or label the assumption unvalidated |
 | Support interrupts every sprint | Quantify interruption demand and agree intake/capacity changes; route flow design to kanban-guru |
 | Teams finish separate components but integration fails | Establish shared integration evidence before reporting capability complete |
 | Audit evidence is required | Include evidence creation in work and acceptance; iteration does not waive obligations |
 | AI output quality is probabilistic | Define evaluation dataset, acceptance criteria, review authority and fallback with ML/agent specialists |
 ## Lightweight and expert use
 A team without a PM can start with one visible ordered work list, one shared outcome,
 accepted-work evidence, and a brief review. Call this a lightweight adaptive setup
 unless the full chosen framework is actually being followed. An expert TPM usually
 needs an exception summary and impact on commitments, not a ceremony redesign.
 Complete when the next learning/delivery outcome, evaluator, capacity assumptions,
 and effect on project commitments are clear.
@@ -0,0 +1,75 @@
 # Real-world cases and transfer limits
 Use when testing a proposed practice against experience. Source IDs resolve in the
 source index. Findings are paraphrased narrowly; proposed controls are our
 interpretation. These are illustrative cases, not a controlled comparison of methods.
 ## Healthcare.gov: visible progress without reliable control
 **Context and evidence:** The 2013 marketplace launch involved multiple systems and
 contractors. GAO's 2014 audit (C01) connected changing requirements and oversight
 gaps with increased costs and schedule slippage. Its 2015 review (C02) identified
 incomplete testing, weak requirements management, and an unreliable schedule; later
 recommendation updates document corrective actions.
 **Our inference:** A dashboard cannot compensate for uncertain scope and missing
 integration evidence. **Proposed control:** reconcile current scope, remaining work,
 and acceptance evidence before assigning project health. Require a specific decision
 when an external deadline and demonstrated readiness conflict.
 **Transfer limit:** This does not establish that a particular framework caused the
 failure or that a startup needs federal acquisition governance. **Test question:**
 what evidence could make you withdraw today's green status?
 ## GitHub's MySQL upgrade: coordination before cutover
 **Evidence (C03):** GitHub reports upgrading more than 1,200 hosts, with preparation
 and execution taking over a year across teams and without impact to its SLOs. Its
 account describes compatibility testing, a rolling calendar and issue checklists
 for app/database coordination, gradual upgrades, and rollback preparation.
 **Our inference:** Prerequisite readiness and handoff agreements belong in the
 project plan. **Proposed control:** track receiver acceptance and rollback evidence
 alongside each scheduled migration wave, with a decision owner for conflicts.
 **Transfer limit:** This is self-reported success in a specific architecture. Do
 not copy its database topology, rollback assumptions, or duration to another system.
 **Test question:** can each team identify the evidence needed before its next handoff?
 ## Mars Climate Orbiter: interfaces and escalation
 **Evidence (C04):** NASA's retrospective briefing identifies a units mismatch plus
 inadequate interface verification, missing end-to-end testing evidence, incomplete
 communication of navigation concerns, and readiness weaknesses around the 1999 loss.
 **Our inference:** Naming an interface is insufficient unless someone verifies it
 and unresolved concerns reach an accountable decision-maker. **Proposed control:**
 include contract version, receiving-team verification, escalation trigger, and
 fallback readiness in dependency agreements.
 **Transfer limit:** A spacecraft's irreversibility differs from a reversible web
 release. The lesson is proportional verification and escalation, not treating every
 software update as a mission launch. **Test question:** who must act if the receiving
 team sees an unexplained mismatch?
 ## GOV.UK: the end of migration is a new operating context
 **Evidence (C05):** GDS's 2015 account reports completing the single-domain transition
 and shifting priorities away from organizations' migration timetables toward
 supporting and improving the service, with team and goal changes.
 **Our inference:** A successful migration milestone does not settle ongoing
 ownership or service priorities. **Proposed control:** obtain accepted operational
 ownership and a benefits-review handoff as part of project closure.
 **Transfer limit:** A leadership account does not independently verify all benefits
 or prove its organization design fits another team. **Test question:** what changes
 in ownership and decision cadence after the project team disbands?
 ## Using cases responsibly
 Compare uncertainty, scale, reversibility, incentives, authority, and dependency
 structure before transferring a lesson. Seek a counterexample or local evidence
 that would invalidate the analogy. Do not manufacture a small-team case by shrinking
 one of these organizations. Hypothetical worked examples in other references are
 labeled explicitly and are not part of the field evidence.
@@ -0,0 +1,56 @@
 # Change control and troubled-project recovery
 Use for scope additions, missed milestones, lost sponsors, unreliable plans, or
 repeated surprises. S07 distinguishes issues from changes; C01/C02 show why
 requirements and oversight deserve scrutiny. The recovery sequence is synthesis.
 ## Handle a proposed change
 1. Capture source, reason, urgency, and outcome sought. Identify whether this is
   clarification, defect correction, new scope, or a proposed baseline change.
 2. Compare the accepted scope and acceptance criteria. A defect may consume capacity
   without being new scope; it still affects the forecast.
 3. Obtain technical impact from relevant owners. Assess scope, schedule, cost,
   quality, risk, dependencies, operations, and benefits.
 4. Present accept, reject, defer, and swap-scope options where feasible. Show the
   impact of doing nothing. Do not assume every dimension can remain fixed.
 5. Route to the authority matching the affected tolerance. Record their decision.
 6. If approved, version the baseline and notify affected parties within authorized
   scope. Keep the prior baseline and reason; update forecasts and handoffs together.
 Pre-approval analysis is allowed. Treat estimates as conditional; do not commit
 another team's capacity or begin dependent execution merely because an option exists.
 ## Recover a troubled project
 Start with a bounded diagnostic, not a ceremony overhaul. Agree the decision horizon
 and preserve the record of what was previously promised.
 - Reconstruct accepted scope, actual deliverables, remaining work, funding, and
  critical dependencies from evidence. Treat percentages without evidence as claims.
 - Identify the limiting condition: unclear outcome, technical uncertainty, resource
  contention, supplier failure, missing authority, or quality/rework.
 - Protect essential work while evaluating reversible changes. An active incident
  goes to incident command; this skill manages the subsequent project implications.
 - Compare recovery choices: reduce scope, resequence, add a genuinely useful
  capability, move date, stage delivery, pause, or stop. Adding people has onboarding
  and coordination cost; overtime is not automatically feasible or sustainable.
 - Get explicit acceptance for the chosen path and its residual risks. Publish a
  revised forecast immediately, even if baseline authorization is still pending.
 - Verify recovery at a short evidence checkpoint. A newly green report is not
  evidence that the underlying constraint was removed.
 ## Hard cases
 | Condition | Required response |
 |---|---|
 | Sponsor insists on same scope/date/cost despite infeasibility | State conflict, assumptions and consequences; seek authorized tradeoff, do not fabricate a compliant plan |
 | Sponsor leaves | Identify interim authority; preserve commitments and escalate decisions that cannot wait |
 | Vendor conceals progress | Request acceptance evidence and contract-authorized remedies through procurement/legal |
 | Risk acceptance requested without technical review | Obtain specialist evidence; a PM status decision cannot waive reserved approval |
 | Team proposes deleting the old baseline | Retain history; distinguish revised plan from original performance |
 | Requirements are not approved | Produce diagnosis/options; route formal implementation planning upstream rather than bypass its gate |
 Complete when a recovery/change decision is supported by evidence and authority,
 or when the exact blocked decision and missing input are reported. Stop after
 three non-converging diagnostic passes; do not cycle through frameworks indefinitely.
@@ -0,0 +1,49 @@
 # Closure and transition
 Use for completed delivery, cancellation, pause, or transfer into ongoing service.
 Basis: S06 calls for managed transition and accepted operational responsibility;
 C05 illustrates a transition from migration-driven work to ongoing service needs.
 ## Separate four decisions
 1. Is the deliverable accepted against the agreed outcome and criteria?
 2. Is it ready to operate or release? Production-readiness and release-engineering
   supply the technical evidence and accountable launch decision.
 3. Can the temporary project organization close or change its mandate?
 4. Who will measure benefits later, and when?
 Do not keep a project open forever just because benefits take time to measure.
 Equally, deployment does not establish adoption, value, or acceptance.
 ## Closure procedure
 Compare accepted outcomes with the latest approved scope and original commitment.
 List incomplete items and disposition: finish before closure, transfer to an
 accepted owner with capacity/date, cancel with authority, or explicitly accept a
 residual limitation. A residual list without receiving owners is not a handoff.
 Confirm support ownership, incident escalation, training, documentation access,
 operating budget, supplier arrangements, and the specialist's recovery plan. Verify
 that the receiving team has actually accepted the transfer. For transition-heavy
 projects, include a bounded stabilization period with exit signals rather than
 indefinite informal support by the delivery team.
 Reconcile remaining financial commitments with the appropriate finance owner.
 Archive decision and acceptance evidence under existing retention rules. Do not
 delete systems, data, accounts, or contracts as an implicit part of closure.
 Record lessons as observations, plausible explanations, and changes to try. Route
 product outcomes to product-lifecycle-learning and incidents to incident-learning.
 ## Cancellation or pause
 Record who decided, why continued investment is not justified or cannot proceed,
 what usable value remains, outstanding obligations, who owns safety/support, and
 whether a revisit is scheduled. Sunk cost alone does not justify continuation.
 A pause needs a restart condition and owner; otherwise it becomes invisible WIP.
 ## Exit
 Closure is complete when acceptance or cancellation is authorized, residual
 obligations have accepted owners, ongoing operation is handed off, and the benefit
 review has an owner and trigger. Report unresolved conditions explicitly instead
 of issuing an unconditional completion statement.
@@ -0,0 +1,65 @@
 # Project control and communication
 Use for recurring reviews, executive updates, disputed status, or escalation.
 Basis: C02 documents weak oversight and stale planning evidence; S06 places
 reporting, issues, and decision-making within project control. This cadence is a
 suggested lightweight adaptation, not a prescribed standard.
 ## A minimum viable review
 Use an existing team cadence; default to an async weekly project review with live
 discussion only for decisions or unresolved conflict. High-risk work may need more
 frequent review. Never delay material bad news until the next meeting.
 1. Read accepted milestones and new evidence since the last review.
 2. Compare baseline, current forecast, and deadline. Ask what remaining work changed.
 3. Inspect blocked/aging dependencies, current issues, and leading risk signals.
 4. Review capacity and cost exposure, including unplanned work displacing commitments.
 5. Identify decisions due before the next review, available options, and consequences
   of waiting. Ask the authorized owner rather than assembling consensus by default.
 6. Issue a concise update and record the next evidence checkpoint.
 ## Status semantics
 Agree thresholds for this project. A useful starting vocabulary is:
 - **On track:** current evidence supports the approved commitment within tolerance.
 - **At risk:** a credible threat needs mitigation or decision; commitment not yet lost.
 - **Off track:** forecast breaches tolerance or acceptance cannot be met as agreed.
 - **Unknown:** evidence is missing, contradictory, or stale enough to affect judgment.
 Report by dimension when necessary: schedule green, quality unknown is not an
 unqualified green project. Do not average away a failed critical dependency. Keep
 the assessment's as-of date and evidence. A ticket marked done without acceptance
 is a discrepancy to resolve, not an excuse to claim delivery.
 ## Risks, issues, assumptions, decisions
 A risk is an uncertain event; an issue has occurred or requires resolution now.
 When a risk materializes, link it to the issue and activate the response. Each risk
 needs an impact, owner, signal, mitigation, contingency, and review trigger. A
 probability-impact score helps sorting but does not replace judgment about severe
 outcomes. Record assumptions with an expiry or invalidation event. Decisions need
 options, authority, rationale, and affected commitments.
 ## Communicate at the audience's pace
 For an expert TPM or sponsor: lead with what changed, impact, recommendation,
 decision required, and latest useful decision date. Link detail. For a team new
 to project management: pair each request with the reason it helps their work.
 Neither audience needs a glossary appended to every update.
 For conflict, separate facts from differing objectives. Show at least two feasible
 options with who benefits, who bears cost, and what becomes impossible. Escalate
 when the relevant decision rights are absent or contested. Do not manufacture
 agreement or silently reassign ownership.
 ## Edge conditions and exit
 A request to "make the report green" does not change evidence. Prepare a truthful
 report with recovery options. A user asking to send it is a separate external action;
 apply authorization before posting. Avoid individual productivity rankings from
 commits, tickets, or time online. These measures do not establish performance.
 Complete when the user has the update or decision brief, each material uncertainty
 is visible, and next actions have accepted owners or explicit ownership gaps.
@@ -0,0 +1,62 @@
 # Engagement and initiation
 Use for a new project, inherited project, missing PM role, or unclear mandate.
 Basis: S06 establishes proportionate governance and explicit accountability.
 The interaction and triage sequence below is original application.
 ## Start where the user is
 Read the brief, current plan, most recent status, decisions, and authoritative
 tracker before interviewing people. Identify which sources are current and who
 can resolve contradictions. Ask only questions that change the immediate decision.
 Do not demand a complete charter before helping with a blocking dependency.
 Preserve the existing board. Do not assign a per-person WIP limit or redesign
 workflow columns without a flow diagnosis; route that work to kanban-guru.
 | Context | First useful output | Avoid |
 |---|---|---|
 | Team without PM | One-page outcome/ownership brief, next milestone, short blocker list | Certification jargon or a meeting-heavy PMO |
 | Practicing TPM | Changes since last review, critical assumptions, options and recommendation | Definitions of terms they already use |
 | Inherited project | Evidence inventory and disputed commitments | Treating last week's green report as the baseline truth |
 | Unapproved idea | Discovery questions and an options/authorization brief | An execution schedule masquerading as a harmless draft |
 For expert requests, use the user's requested format and decision horizon. Give
 feedback that improves their judgment: show the missing dependency, weak evidence,
 or tradeoff, and its consequence. Offer explanation only where the reasoning is
 non-obvious or requested. Do not label the person a novice based on job title.
 ## Establish the minimum project contract
 Capture outcome and acceptance authority; included and excluded scope; business
 reason; hard versus negotiable constraints; known capacity and skills; external
 interfaces; source of funding; decision rights; and the next decision date.
 Distinguish an actual deadline from a desired date and record its source.
 A small team can combine sponsor, delivery coordinator, and technical lead roles,
 but name which decisions each role can make. A coordinator does not acquire
 architecture, budget, product-priority, or risk-acceptance authority by tracking
 work. Get explicit acceptance for new commitments, not merely a name in a table.
 Use the project-brief template only to fill real gaps. Link existing approval
 records instead of recreating them. Unanswered fields remain unknown with a
 proposed owner and evidence request. Proposed owners are not accepted owners.
 ## Inheriting unreliable records
 1. Save the stated baseline and source date; do not overwrite history.
 2. Separate accepted deliverables from claimed percentages and open work.
 3. Compare tracker records with integration evidence and receiving-team acceptance.
 4. Identify the earliest consequential decision: funding, vendor commitment,
   launch date, or safety concern.
 5. Issue a provisional health assessment with evidence gaps and a short recovery
   investigation; prioritize gaps that could reverse that decision.
 For a volunteer or part-time team, ask about sustainable availability and absence
 coverage. Do not convert headcount into full-time capacity. For distributed teams,
 record working calendars and the latency of cross-time-zone decisions.
 ## Exit
 The immediate decision, authoritative sources, current mandate, and owner of each
 material gap are visible. Stop setup when these are adequate. Missing approval
 blocks commitments and execution authorization, not read-only diagnosis.
@@ -0,0 +1,61 @@
 # Evaluation and validation guide
 Use when assessing whether the skill improves real outputs. A schema-valid manifest
 is not behavioral proof, and a fake-adapter CI pass is only a harness smoke test.
 ## Scenario coverage
 The eval manifest covers a team without a PM, expert vendor-slippage analysis,
 hardware/software hybrid work, misleading green status, shared-resource arithmetic,
 fixed-constraint change, uncertain AI research, closure gaps, Scrum accountabilities,
 case-transfer limits, regulatory/appetite conflict, and inherited baseline integrity.
 Neighboring skills also test routing of ongoing project control to this skill.
 ## Behavioral protocol
 Run selected cases in fresh contexts with the skill and without it. Supply the same
 prompt and input files to both. Keep baseline contexts free of the skill's content;
 do not describe its expected answer. Store outputs separately. Grade each observable
 assertion against actual output evidence and retain failures. Record tested revision,
 model/harness if available, input, actual output, grade, and limitations. Unknown
 runtime metadata stays unknown, not invented.
 Start with the expert slippage, no-PM, and resource-conflict cases. Expand to the
 remaining cases after reviewing quality. A single paired run does not establish a
 statistically reliable improvement. Avoid aggregate "world-class" or general
 reliability claims. Changes that make the skill longer without improving decisions
 should be reconsidered. Preserve case IDs when refining assertions.
 ## Separate trigger probes
 These are manual trigger checks, not portable output-quality cases:
 | Prompt | Expected routing |
 |---|---|
 | Help our team run this project; nobody is a PM | This skill |
 | I need a sponsor decision about a slipped vendor milestone | This skill |
 | How should we close and hand off this technical project? | This skill |
 | Write the code to fix this API error | Engineering specialist |
 | Diagnose our WIP limit and cycle time | Kanban guru |
 | Turn this approved spec into a work breakdown | Implementation planning |
 | Move a Jira issue to Done | Jira |
 ## Mechanical checks
 From repository root, run skill-local tests, format/link validation, changed-skill
 quality validation, eval schema validation and coverage ratchet, skill-test discovery,
 and generated catalog checks. These prove structure and deterministic software
 behavior, not the quality of every management recommendation.
 Run the helper tests directly with:
 ```sh
 python3 -m unittest discover -s technical-project-management/scripts -p 'test_*.py'
 ```
 Complete evaluation reporting when actual checks and sampled outcomes are recorded,
 failures have dispositions, and untested claims remain explicitly untested.
 The initial sampled review and captured outputs live in `evals/sample-review.md`
 and `evals/samples/` under the skill root. It documents no observed score advantage,
 limited isolation, post-review refinements, and the cases not yet exercised.
@@ -0,0 +1,55 @@
 # Flow, scarce capacity, and bounded bets
 Use when interruptions, queues, shared specialists, or appetite-based work affect
 project commitments. Source basis: S03 (flow), S09 (bounded bets), S10 (resource
 readiness). Detailed Kanban and Shape Up practice stays with existing specialists.
 ## Flow-based projects
 Kanban makes workflow and work-in-progress policies explicit and inspects delivery
 flow (S03). Route board design, classes of service, service-level expectations, and
 flow forecasts to kanban-guru. This skill translates those outputs into project
 milestones and stakeholder decisions.
 Check that completion history excludes unfinished work and that blocked work stays
 visible. A queue boundary changing halfway through the sample makes trends difficult
 to compare. Keep expedite demand visible, including which planned work it displaces.
 Do not promise an initiative's completion from a single item's service expectation.
 ## Critical chain as a constraint lens
 Resource readiness can govern completion even where the dependency graph permits
 parallel work (S10). Before accelerating activity, identify the scarce capability,
 sequence competing demands, and secure availability. Resource buffers are readiness
 signals; schedule buffers protect time. Neither is a license to invent capacity.
 Use this sequence as a practical adaptation:
 1. Map all material demands on the shared specialist, including operations.
 2. Name a human authority for conflicting priorities across projects.
 3. Agree a feasible sequence; record external promises before changing them.
 4. Identify protected contingency, what consumes it, and when to escalate.
 5. Recheck forecast after interruption, absence, or predecessor slippage.
 Do not apply a universal buffer-size rule or promise a fixed percentage speedup.
 The bundled schedule tool does not implement critical-chain scheduling or resource
 leveling. Route large resource-constrained schedules to appropriate scheduling
 expertise/tools and bring the result back into the control record.
 ## Appetite-based work
 Basecamp describes committing protected capacity to a shaped bet for a bounded
 cycle and reconsidering work that overruns rather than extending automatically
 (S09). Route shaping and detailed Shape Up practice to product-shaping.
 Project management still tracks external dependencies, acceptance, non-negotiable
 quality, and consequences of stopping. Appetite is willingness to invest, not an
 estimate that proves feasibility. An immovable regulatory deliverable cannot simply
 be discarded at the cycle boundary; surface that incompatibility before selecting
 this approach. Protect scope flexibility without hiding essential work.
 ## Exit
 The limiting resource or flow policy is identified, the next experiment or capacity
 decision is owned, and the effect on the project forecast is explicit. Do not
 redesign the whole team operating model to answer a single schedule question.
@@ -0,0 +1,89 @@
 # Forecasting, cost, and schedule analysis
 Use for "when will it finish?", date confidence, critical-path changes, or cost
 exposure. S04 supports the need for credible schedule logic and schedule-risk
 analysis. The model-selection procedure and calculator are original implementations.
 ## Match the model to the evidence
 - Stable, dependent deliverables: inspect the network and remaining durations.
 - Repeated comparable work: use historical throughput/flow forecasting through
  kanban-guru, preserving its assumptions and observation window.
 - Novel research or unstable scope: offer scenarios and an early learning gate.
  Do not manufacture probability distributions from guesses.
 - Material funding decisions: maintain actual cost plus estimate to complete;
  route model construction to financial-modeling.
 Keep **baseline commitment**, **current forecast**, **required deadline**, and
 **actual acceptance** separate. A forecast is conditional; a commitment is an
 accountable decision. More decimal places do not improve weak inputs.
 ## Forecast review
 Capture as-of date, remaining scope, done criteria, available capacity, exclusions,
 model, assumptions, and sources. Review calendar effects, parallelism, scarce
 skills, rework, supplier waits, and uncertainty correlations. If all paths depend
 on the same test lab, they do not fail independently.
 For probabilistic forecasts, state the sample, comparable conditions, simulation
 method, confidence level, and events outside the model. Small or changing samples
 are limitations, not proof of a precise percentile. Separate forecast calibration
 from whether a target was politically accepted. Revisit after material scope or
 capacity changes; compare forecast with actual delivery to learn.
 For budgets, distinguish approved funding, actuals, committed but uninvoiced spend,
 remaining estimate, and contingency. Avoid counting a purchase in both actuals and
 commitments. Earned value is useful only with a credible time-phased cost baseline
 and objective earning rules; ticket percentages are not automatically earned value.
 Do not compare SPI to calendar-day delay. Record financial assumptions for review.
 ## Read-only schedule helper
 Run from the skill root:
 ```sh
 python3 scripts/schedule.py --input templates/schedule-example.json --json
 python3 -m unittest discover -s scripts -p 'test_*.py'
 ```
 Input is a JSON object with `schema_version: 1`, `unit: "working_days"`, and
 `tasks`: 1–500 objects. Each task has a unique non-empty `id`, nonnegative finite
 `duration` (elapsed working days, not person-days), and `depends_on` list. Optional
 `resource` identifies a single exclusive resource; it detects overlapping demand
 but does not schedule it. Optional `deadline` is a nonnegative working-day offset
 from project start. No dates, calendars, lags, partial progress, or unknown fields
 are accepted. Use zero-duration tasks for milestones; they occupy no resource time.
 The algorithm topologically sorts finish-to-start dependencies, performs a forward
 pass for earliest times and a backward pass against the unconstrained finish for
 float. It returns all zero-float task IDs (which may span multiple paths), finish
 offset, deadline gap, and resource overlaps (first 100 pairs plus total count and truncation flag).
 `deadline_gap = finish - deadline`;
 positive is late. Float is relative to modeled finish, not the requested deadline.
 This is a lower bound under precedence constraints and assumed durations. It is
 not a resource-leveled schedule, Monte Carlo model, working-calendar converter,
 critical-chain implementation, or completion promise. A resource warning means the
 earliest dates conflict; resequence in the source plan and recalculate. Other
 resource conflicts can exist even if no resource labels were supplied.
 The script performs no network calls and mutates no files. JSON goes to stdout;
 invalid input errors go to stderr with exit 2. Success is exit 0, including a late
 forecast: lateness is data, not malformed input. Boundaries: 1 MB input, at most
 500 tasks, finite aggregate duration no larger than one million working days.
 ## Interpretation example
 Design takes 2 days. Build (3 days) and review preparation (1 day) depend on design.
 Acceptance (1 day) requires both. Finish is day 6; design, build, and acceptance
 have zero float; review preparation has 2 days float. If build and review preparation
 need the same exclusive person, the apparent parallel schedule conflicts. Do not
 report day 6 as a feasible commitment without resolving that conflict.
 Complete when the forecast and its uncertainty are stated, contradictions are
 visible, and the decision-maker understands what must change to meet the target.
 For this small example, one exclusive specialist must do build and review
 preparation serially: 2 + 3 + 1 + 1 = 7 working days. A second specialist restores
 the dependency-only day 6; it cannot by itself achieve day 5. For a small network,
 show such a feasible sequence explicitly; do not imply the helper leveled it.
@@ -0,0 +1,56 @@
 # Hybrid delivery and dependency coordination
 Use when teams, vendors, procurement, hardware, or governance work on different
 cadences. Basis: S01/S06 support tailoring; C03 supplies a real coordination
 example. The interface procedure below is this skill's synthesis.
 ## Define a hybrid precisely
 Name which work follows which approach, why, and who owns each interface. A
 monthly sponsor decision can coexist with continuous software delivery; it must
 not secretly require every team to wait for a monthly release. Conversely, a
 sprint review cannot override a required external certification.
 Maintain one authoritative milestone/decision view. Team backlogs can differ;
 project commitments cannot contradict each other without a visible unresolved
 issue. Do not impose a shared sprint length merely to simplify reporting.
 ## Dependency agreement
 For each material dependency record: provider, receiver, deliverable and version,
 acceptance evidence, needed-by date, provider forecast, accepted commitment,
 confidence basis, review date, escalation owner, and fallback. A provider saying
 "we'll try" is a forecast or aspiration, not a commitment.
 1. Ask the receiver what usable input is needed, not just which team is blocking.
 2. Validate whether it is a hard dependency. A mock may permit development but not
   production acceptance; document both boundaries.
 3. Confirm the provider's scope and capacity. Include procurement lead time,
   reviews, security, test environments, and customer participation.
 4. Schedule an integration checkpoint before the final milestone. Agree how a
   failed handoff changes the forecast and who decides the response.
 5. Track interface changes and receiver acknowledgement. A delivered artifact is
   not an accepted handoff until the receiving party can use it as agreed.
 ## Vendor and distributed-team cases
 | Problem | Response |
 |---|---|
 | Fixed-price vendor with evolving software needs | Identify contractual acceptance/change process; assess options with procurement/legal rather than interpreting rights yourself |
 | Vendor dates lag the project need | Record date gap and latest decision point for contingency; escalate before the fallback becomes impossible |
 | Shared environment unavailable | Treat environment capacity as a dependency, with a specific reservation owner |
 | Time-zone handoffs add a day per question | Use an async decision brief, clear response window, and backup decision-maker |
 | Two teams claim contract ownership | Separate authoring, approval, and acceptance responsibilities; route unresolved authority to the sponsor |
 | Several projects compete for one team | Surface program/portfolio arbitration; do not allocate another project's capacity unilaterally |
 ## Worked boundary (hypothetical)
 A vendor provides a certified device in week 8; software teams iterate fortnightly.
 The project has interface test evidence due in week 5 and integrated acceptance in
 week 9. If certification moves to week 10, successful software sprints do not keep
 the project green. Present a revised integration forecast, impact on commitments,
 and an authorized fallback decision. A simulator retires interface uncertainty but
 does not replace device certification.
 Complete when critical handoffs have accepted owners, evidence, dates, and escalation
 paths, or their absence is explicitly blocking the affected commitment.
@@ -0,0 +1,58 @@
 # Select and tailor the approach
 Use when choosing a method or when delivery pain suggests the current method no
 longer fits. Basis: S01's fit-for-purpose argument and S06's distinction among
 delivery approaches. This decision procedure is a practical synthesis, not a
 certification decision tree or a ranking of methodologies.
 ## Diagnose before prescribing
 Inspect six things: requirement stability, technical uncertainty, ability to
 release partial value, cost of reversing a decision, external timing constraints,
 and actual team autonomy/capacity. Also identify mandatory governance. A team
 calling its work agile does not prove these conditions hold.
 Default to the team's existing adequate approach. Change it only to address an
 observed problem. Do not use a weighted score to hide a veto condition such as an
 unavailable safety approver or impossible vendor lead time.
 | Conditions | Candidate | First check | Failure signal / response |
 |---|---|---|---|
 | Known deliverable, stable interfaces, expensive irreversible steps | Predictive with staged decisions | Is the dependency plan feasible with actual resources? | Repeated late changes: shorten planning horizon and add discovery |
 | Need to learn what works through feedback | Iterative | Who evaluates the experiment and when? | No feedback access: resolve it before committing more cycles |
 | Useful components can be accepted separately | Incremental | Does each increment work end to end? | Layer-only milestones: redefine around usable capability |
 | Cohesive team, clear product authority, regular inspect/adapt cycle | Scrum | Can the team protect a goal and meet a shared quality bar? | Many unrelated interruptions: fix intake/capacity, consider flow |
 | Variable arrival, support work, aging queues | Flow-based/Kanban | Are start/finish and capacity policies explicit? | WIP growth: investigate bottleneck before adding work |
 | Scarce resources repeatedly delay otherwise independent work | Critical-chain lens | Are resource contention and readiness visible? | Treating buffers as hidden padding: make them explicit and owned |
 | Bounded product opportunity, discretionary scope, protected capacity | Appetite-based/Shape Up | Can leadership actually protect the bet? | Mandatory scope exceeds appetite: reshape or choose a different model |
 | Hardware/vendor stages plus evolving software | Hybrid | Who accepts the cross-method interfaces? | Two conflicting plans: establish one milestone/decision record |
 Predictive is a planning approach; Scrum is a framework; critical path and critical
 chain are scheduling techniques; PRINCE2 is a project management method; Kanban
 manages flow. They are not interchangeable alternatives at one abstraction level.
 Stage governance can coexist with iterative delivery. Iterative learning does not
 necessarily produce a releasable increment; incremental delivery need not entail
 high uncertainty. Do not call all of these "agile" without qualification.
 ## Make the choice actionable
 Write an approach decision: observed conditions, selected approach, nearest rejected
 alternative, who decides scope and dates, cadence, required evidence, and revisit
 trigger. Define the first inspection point. Explain only the tradeoff the user
 needs, rather than reciting the whole matrix.
 Example (hypothetical): a device project has a long-lead board order and uncertain
 calibration software. Use a staged procurement decision for hardware and short
 software learning cycles, tied to an integrated prototype acceptance milestone.
 Do not let software sprint completion imply the device is ready for certification.
 ## Edge cases and exit
 Mandatory organizational methods constrain tailoring: surface a justified exception
 request rather than quietly replacing the method. A small team does not need
 separate meetings for every practice. A multi-project program may need an additional
 benefits and governance owner; expose that need instead of promising this skill
 replaces enterprise program management.
 Complete when one approach and its adaptations address the diagnosed conditions,
 its coordination contract is explicit, and a review trigger exists.
@@ -0,0 +1,53 @@
 # Predictive planning and stage governance
 Use for stable deliverables, external approvals, procurement, regulated work, or
 irreversible commitments. Basis: S04 supports credible schedule logic; S06 supports
 proportionate governance. S08 establishes PRINCE2 as a tailorable method, but this
 reference is not a complete PRINCE2 manual.
 ## Operate the project
 1. Define verifiable outputs and acceptance owners before linking dates. Include
   integration, review, supplier lead time, operational preparation, and acceptance.
 2. Have implementation-planning produce or update the approved work breakdown.
   Ask contributors for durations and availability; document calendar assumptions.
 3. Establish the baseline version and authorized tolerances for time, cost, scope,
   quality, and risk. Do not invent default percentage tolerances.
 4. Divide authorization at meaningful uncertainty or investment boundaries. Each
   stage decision needs evidence of the prior output, a current remaining-work
   forecast, unresolved risks, and a decision about continued justification.
 5. Update forecasts using actual starts/finishes and remaining durations. Inspect
   path changes and resource conflicts before treating a milestone date as feasible.
 6. Escalate predicted tolerance breaches early with options. A stage review is a
   decision about proceeding, changing, pausing, or stopping, not a slide approval.
 ## Avoid false precision
 A detailed plan can still be unreliable if its dependencies are missing. Dates
 entered as constraints to force the target can conceal the very slippage the model
 should expose. Distinguish effort (person-days) from elapsed working duration;
 review queues, unavailable specialists, and supplier waits break simple conversion.
 A critical path is not a static set of red tasks. Recompute after changes and watch
 near-critical paths. A zero-float task may be critical to the modeled finish but
 not yet resource-feasible. Schedule contingency needs an explicit owner and drawdown
 policy; never count the same risk both in every task and again as a project buffer.
 ## PRINCE2-informed boundaries
 Separate issue capture from change authorization (S07): a reported defect,
 question, opportunity, or concern is not automatically a change to the baseline.
 Assess the effect and use the appropriate authority. When users require formal
 PRINCE2 adoption, consult their authorized edition and governance arrangements;
 do not infer compliance from these generic artifacts.
 ## Failure signals
 - Every task is "90% done": replace percentage claims with remaining-work evidence.
 - Approvals appear only at the end: ask what evidence approvers need early.
 - Review capacity is absent from the schedule: reserve it or revise the forecast.
 - A fixed date and fixed scope exceed available capacity: present a conflict and
  concrete options, not overtime as an automatic remedy.
 Complete when the next stage is decision-ready and material forecast changes have
 an accountable response. Delivery assurance remains with technical specialists.
@@ -0,0 +1,64 @@
 # Research brief and coverage map
 ## Purpose and plan
 Build a technical project management methodology for teams without a dedicated PM
 and experienced TPMs. Own the continuous management loop from initiation through
 closure. Preserve existing specialists' ownership of detailed implementation
 planning, product choices, flow design, engineering, and release mechanics.
 Implementation sequence: research primary guidance and cases; map ownership;
 write conditional references and reusable artifacts; add a bounded schedule
 analysis tool; exercise difficult scenarios and script edge cases; validate the
 catalog; publish and review the change. No claim of superior delivery outcomes
 follows merely from shipping this bundle.
 ## Research method
 Sources were inspected on 2026-09-05. Prefer framework owners for definitions,
 independent audits for failure findings, and first-person engineering accounts for
 operating details. Check edition and distinguish event date from publication date.
 Do not count search snippets as full-report review. The source index identifies
 exact sections inspected and evidence limitations. Original procedures and templates
 are this repository's synthesis, not quotations or claims of certified compliance.
 The initial 2020 GAO Agile exposure draft was superseded in this research by the
 2023 revised guide. Standards for government apply within their jurisdiction;
 transferable practices do not make their requirements universal.
 ## Coverage and ownership
 | Need | This skill owns | Specialist boundary |
 |---|---|---|
 | Starting or inheriting a project | Mandate, authority, uncertainty, baseline discovery | Product discovery validates the problem; implementation planning requires approved input |
 | Choosing a method | Fit, adaptation, coordination across methods | Kanban guru owns detailed flow design; product shaping owns Shape Up shaping |
 | Execution | Milestone evidence, commitments, issues, decisions, scope changes | Engineering specialists implement; Jira/Linear operate systems |
 | Forecasting | Model choice, assumptions, resource feasibility, forecast versus promise | Implementation planning owns the detailed dependency plan |
 | Governance | Project tolerances and escalation | Product governance and executive strategy retain their own authority |
 | Closure | Acceptance, residual owners, operational handoff, benefit review | Production readiness owns launch evidence; lifecycle learning owns outcome reviews |
 ## Evidence-driven design decisions
 - Keep governance separate from delivery cadence (GovS 002, PMI tailoring).
 - Require observable progress and current remaining work, not optimistic color
  labels (GAO Healthcare.gov findings).
 - Treat interfaces and escalation as management work (NASA MCO review).
 - Track readiness and coordination before production dates (GitHub upgrade case).
 - Include transition to ongoing service, not only shipping (GOV.UK case).
 - Protect team accountabilities when adding coordination (Scrum Guide).
 - Do not promise that any branded method is universally faster (PMI evidence is
  contextual; practitioner accounts are not controlled comparisons).
 ## Acceptance and limitations
 Acceptance requires a thin entry point, reachable references, useful templates,
 valid output-quality evals, tests for any bundled executable, source-to-practice
 traceability, and passing repository checks. Behavioral tests must distinguish
 actual outputs from expected outcomes and record revision and limitations.
 Cases deliberately include public and private organizations, failures and reported
 successes. They are not a representative sample. Small volunteer teams, early-stage
 startups, and high-uncertainty AI research are covered by labeled adaptations and
 scenario tests, not invented field evidence. Expand the case library when credible
 first-person artifacts become available. Do not label the skill "world-class" as
 an established result of structural validation.
@@ -0,0 +1,43 @@
 # Source index and evidence ledger
 Inspected 2026-09-05. IDs are stable citations used throughout the bundle. This is
 an evidence ledger of paraphrases and original applications, not an archive of
 copyrighted publications. No full books, standards, or reports are redistributed.
 ## Method and governance sources
 | ID | Source / edition | Material inspected and supported claim | Limits |
 |---|---|---|---|
 | S01 | [PMI, Project Management Embraces the Fit-for-Purpose Approach](https://www.pmi.org/blog/project-management-embraces-the-fit-for-purpose-approach) | Article; approach selection should fit the project rather than impose one framework | Professional-body commentary, not a universal causal comparison |
 | S02 | [Schwaber and Sutherland, Scrum Guide, November 2020](https://scrumguides.org/scrum-guide.html) | Scrum Team, Sprint, artifacts; distinct accountabilities, goals, usable increments, inspection and adaptation | Framework definition, not evidence that Scrum fits every project; original synthesis here, no guide reproduction |
 | S03 | [The Kanban Guide, May 2025](https://kanbanguides.org/the-kanban-guide/) | Workflow definition, active management, improvement, flow measures | Definition-level evidence; detailed application belongs to kanban-guru |
 | S04 | [GAO Schedule Assessment Guide, GAO-16-89G, 2015](https://www.gao.gov/products/gao-16-89g) | Overview and [report](https://www.gao.gov/assets/d1689G.pdf), best-practice headings and critical-path sections; dependency logic, resource feasibility, schedule risk, updating and baseline maintenance | Public capital-program context; the bundled calculator implements only elementary dependency arithmetic |
 | S05 | [GAO Agile Assessment Guide, GAO-24-105506, 2023, revised December 15](https://www.gao.gov/products/gao-24-105506) | Official overview: incremental development, adoption, execution, monitoring and control | Overview inspected; full PDF retrieval failed. Do not attribute detailed checklist requirements to this source. Replaces the 2020 exposure draft |
 | S06 | [Government Project Delivery, GovS 002, v2.1, September 2025](https://projectdelivery.gov.uk/library-products/government-functional-standard-govs-002-project-delivery/) | HTML: principles; 3.4 approach selection; 6 project lifecycle; 7 planning/control; 8.8 transition | Mandated for its UK government scope, not all organizations. HTML reports modification March 2026 |
 | S07 | [PeopleCert, PRINCE2 7 Issues: not every issue equals a change, 2023](https://www.peoplecert.org/news-and-announcements/2023/prince2-7-issues) | Article by co-author Brad Bigelow: capture and assess an issue before treating it as a baseline change | Public explanation only; not a substitute for the licensed manual |
 | S08 | [PeopleCert, PRINCE2 Project Management Practitioner v7](https://www.peoplecert.org/browse-certifications/project-programme-and-portfolio-management/PRINCE2-2/PRINCE2-7-practitioner-3581) | Official overview of principles, practices, processes, and tailoring | Product description; no claim of complete PRINCE2 implementation or certification |
 | S09 | [Basecamp, Shape Up, The Betting Table](https://basecamp.com/shapeup/2.2-chapter-08) | Protected capacity, appetite, cycle decisions, circuit breaker | Creator's operating account; not universal schedule evidence. Product-shaping owns detailed application |
 | S10 | [PMI, Analysis of Resource Buffer Management in Critical Chain Scheduling, 2006](https://www.pmi.org/learning/library/resource-buffer-management-critical-chain-scheduling-8027) | Resource readiness and scheduling under constraints | Conference research paper, not a PMI standard; does not justify universal buffer percentages |
 ## Case sources
 | ID | Source / event context | Evidence inspected | Limits |
 |---|---|---|---|
 | C01 | [GAO, Healthcare.gov contract management, GAO-14-694, 2014](https://www.gao.gov/products/gao-14-694) | What GAO Found: changing requirements and oversight gaps accompanied increased costs and schedule slippage around the 2013 launch | Independent audit, specific federal procurement context |
 | C02 | [GAO, Healthcare.gov development practices, GAO-15-238, 2015](https://www.gao.gov/products/gao-15-238) | What GAO Found and recommendation updates: requirements, incomplete testing, unreliable schedules; subsequent corrections | Separates initial findings from later verified implementation; not proof that changing methodology alone fixes delivery |
 | C03 | [GitHub, Upgrading GitHub.com to MySQL 8.0, December 2023, updated May 2024](https://github.blog/engineering/upgrading-github-com-to-mysql-8-0/) | Preparing the journey, communication, upgrade plan, rollback: staged work with app/database coordination | First-person account; outcome is reported by the organization, not independently audited |
 | C04 | [NASA, Lost in Translation: Mars Climate Orbiter, 2009 safety briefing](https://sma.nasa.gov/docs/default-source/safety-messages/safetymessage-2009-08-01-themarsclimateorbitermishap-vits.pdf) | Proximate cause / underlying issues slide: interface verification, communication, operational readiness in the 1999 loss | Retrospective NASA summary of investigation, not direct access to all project records |
 | C05 | [GDS, The new normal for GOV.UK, June 2015](https://insidegovuk.blog.gov.uk/2015/06/17/the-new-normal-for-gov-uk/) | Transition complete; shift from migration timetable toward running and improving the service | First-person leadership account, not independent benefits evaluation |
 ## Attribution discipline
 In recommendations, distinguish **source finding**, **our inference**, and
 **proposed practice**. The numbered procedures, thresholds to agree with teams,
 templates, and software are original synthesis. No source endorses this bundle.
 Method-specific summaries are deliberately short; consult the primary work when
 its formal rules matter. Preserve authors and editions when updating references.
 Evidence collection is complete for this initial release, not exhaustive. Refresh
 framework editions when a user requests current compliance or formal adoption.
 Retain case event dates: a recently crawled page does not make a historical case
 recent. Contradictory local evidence outranks a superficial analogy to a case.
@@ -0,0 +1,196 @@
 #!/usr/bin/env python3
 """Read-only finish-to-start schedule analysis; not resource leveling."""
 import argparse
 import heapq
 import json
 import math
 import sys
 from pathlib import Path
 MAX_BYTES = 1_000_000
 MAX_TASKS = 500
 MAX_DURATION = 1_000_000
 MAX_CONFLICTS = 100
 def number(value, label):
    if type(value) not in (int, float) or not 0 <= value <= MAX_DURATION:
        raise ValueError(f"{label} must be a finite number from 0 to {MAX_DURATION}")
    return value
 def identifier(value, label):
    if (
        not isinstance(value, str)
        or not value.strip()
        or len(value) > 100
        or any(ord(c) < 32 or ord(c) == 127 for c in value)
    ):
        raise ValueError(
            f"{label} must be nonblank text of at most 100 characters without controls"
        )
    return value
 def fields(value, required, optional, label):
    if not isinstance(value, dict):
        raise ValueError(f"{label} must be an object")
    if not required <= value.keys() or value.keys() - required - optional:
        raise ValueError(
            f"{label}: required fields {sorted(required)}; optional {sorted(optional)}"
        )
 def validate(data):
    fields(data, {"schema_version", "unit", "tasks"}, {"deadline"}, "schedule")
    if type(data["schema_version"]) is not int or data["schema_version"] != 1:
        raise ValueError("schema_version must be integer 1")
    if data["unit"] != "working_days":
        raise ValueError("unit must be working_days (elapsed duration, not person-days)")
    if "deadline" in data:
        number(data["deadline"], "deadline")
    tasks = data["tasks"]
    if not isinstance(tasks, list) or not 1 <= len(tasks) <= MAX_TASKS:
        raise ValueError(f"tasks must contain 1 to {MAX_TASKS} tasks")
    by_id = {}
    for task in tasks:
        fields(task, {"id", "duration", "depends_on"}, {"resource"}, "task")
        key = identifier(task["id"], "task id")
        if key in by_id:
            raise ValueError(f"duplicate task id: {key}")
        number(task["duration"], f"duration for {key}")
        deps = task["depends_on"]
        if not isinstance(deps, list):
            raise ValueError(f"depends_on for {key} must be a list")
        for dep in deps:
            identifier(dep, "dependency id")
        if len(deps) != len(set(deps)):
            raise ValueError(f"duplicate dependency for {key}")
        if "resource" in task:
            identifier(task["resource"], "resource")
        by_id[key] = task
    if sum(t["duration"] for t in tasks) > MAX_DURATION:
        raise ValueError(f"aggregate duration exceeds {MAX_DURATION} working days")
    for key, task in by_id.items():
        for dep in task["depends_on"]:
            if dep not in by_id:
                raise ValueError(f"unknown dependency {dep} for {key}")
            if dep == key:
                raise ValueError(f"self dependency for {key}")
    return by_id
 def analyze(data):
    tasks = validate(data)
    successors = {key: [] for key in tasks}
    indegree = {key: len(t["depends_on"]) for key, t in tasks.items()}
    for key, task in tasks.items():
        for dep in task["depends_on"]:
            successors[dep].append(key)
    ready = [key for key in tasks if indegree[key] == 0]
    heapq.heapify(ready)
    order = []
    timing = {}
    while ready:
        key = heapq.heappop(ready)
        start = max((timing[d]["early_finish"] for d in tasks[key]["depends_on"]), default=0)
        timing[key] = {"early_start": start, "early_finish": start + tasks[key]["duration"]}
        order.append(key)
        for child in successors[key]:
            indegree[child] -= 1
            if indegree[child] == 0:
                heapq.heappush(ready, child)
    if len(order) != len(tasks):
        raise ValueError("dependency cycle: remove circular dependencies before scheduling")
    finish = max(t["early_finish"] for t in timing.values())
    for key in reversed(order):
        late_finish = min((timing[c]["late_start"] for c in successors[key]), default=finish)
        late_start = late_finish - tasks[key]["duration"]
        slack = late_start - timing[key]["early_start"]
        # Decimal working-day inputs may accumulate binary floating-point noise.
        if math.isclose(slack, 0, abs_tol=1e-9):
            slack = 0
        timing[key].update(late_start=late_start, late_finish=late_finish, total_float=slack)
    conflicts = []
    conflict_count = 0
    resource_tasks = {}
    for key in sorted(tasks):
        resource = tasks[key].get("resource")
        if resource and tasks[key]["duration"] > 0:
            for other in resource_tasks.get(resource, []):
                start = max(timing[key]["early_start"], timing[other]["early_start"])
                end = min(timing[key]["early_finish"], timing[other]["early_finish"])
                if start < end:
                    conflict_count += 1
                    if len(conflicts) < MAX_CONFLICTS:
                        conflicts.append(
                            {
                                "resource": resource,
                                "tasks": [other, key],
                                "overlap_start": start,
                                "overlap_finish": end,
                            }
                        )
            resource_tasks.setdefault(resource, []).append(key)
    return {
        "schema_version": 1,
        "unit": "working_days",
        "model": "unconstrained_finish_to_start",
        "finish": finish,
        "deadline_gap": finish - data["deadline"] if "deadline" in data else None,
        "critical_tasks": sorted(key for key in tasks if timing[key]["total_float"] == 0),
        "tasks": [{"id": key, **timing[key]} for key in sorted(tasks)],
        "resource_conflicts": conflicts,
        "resource_conflict_count": conflict_count,
        "resource_conflicts_truncated": conflict_count > MAX_CONFLICTS,
        "warnings": [
            "Earliest times are not resource-leveled or commitments; validate capacity, calendars and uncertainty."
        ],
    }
 def unique_object(pairs):
    result = {}
    for key, value in pairs:
        if key in result:
            raise ValueError(f"duplicate JSON field: {key}")
        result[key] = value
    return result
 def reject_constant(value):
    raise ValueError(f"non-finite JSON number: {value}")
 def read_input(path):
    with Path(path).open("rb") as handle:
        raw = handle.read(MAX_BYTES + 1)
    if len(raw) > MAX_BYTES:
        raise ValueError(f"input exceeds {MAX_BYTES} bytes")
    return json.loads(
        raw.decode("utf-8"), object_pairs_hook=unique_object, parse_constant=reject_constant
    )
 def main(argv=None):
    parser = argparse.ArgumentParser(
        description=__doc__,
        epilog="Exit 0: calculation complete (even if late). Exit 2: invalid input. No files are changed.",
    )
    parser.add_argument(
        "--input", required=True, help="JSON schedule file; see templates/schedule-example.json"
    )
    parser.add_argument("--json", action="store_true", help="Structured output (also the default)")
    args = parser.parse_args(argv)
    try:
        result = analyze(read_input(args.input))
    except (ValueError, OSError, RecursionError) as exc:
        print(f"error: {exc}", file=sys.stderr)
        return 2
    print(json.dumps(result, indent=2, allow_nan=False))
    return 0
 if __name__ == "__main__":
    sys.exit(main())
@@ -0,0 +1,177 @@
 """Hand-calculated networks, malformed-input boundaries, and CLI behavior."""
 import copy
 import importlib.util
 import json
 import subprocess
 import sys
 import tempfile
 import unittest
 from pathlib import Path
 SCRIPT = Path(__file__).with_name("schedule.py")
 spec = importlib.util.spec_from_file_location("tpm_schedule", SCRIPT)
 schedule = importlib.util.module_from_spec(spec)
 spec.loader.exec_module(schedule)
 def task(key, duration, deps=(), **extra):
    return {"id": key, "duration": duration, "depends_on": list(deps), **extra}
 def network(tasks, **extra):
    return {"schema_version": 1, "unit": "working_days", "tasks": tasks, **extra}
 class ScheduleTests(unittest.TestCase):
    def setUp(self):
        self.data = network(
            [task("A", 2), task("B", 3, ["A"]), task("C", 1, ["A"]), task("D", 1, ["B", "C"])]
        )
    def test_diamond_float_and_deadline(self):
        self.data["deadline"] = 5
        result = schedule.analyze(self.data)
        self.assertEqual(result["finish"], 6)
        self.assertEqual(result["deadline_gap"], 1)
        self.assertEqual(result["critical_tasks"], ["A", "B", "D"])
        timings = {t["id"]: t for t in result["tasks"]}
        self.assertEqual(timings["C"]["total_float"], 2)
        self.assertEqual(timings["D"]["early_start"], 5)
    def test_tied_paths_and_disconnected_task(self):
        result = schedule.analyze(
            network([task("A", 2), task("B", 2), task("join", 0, ["A", "B"]), task("C", 1)])
        )
        self.assertEqual(result["critical_tasks"], ["A", "B", "join"])
        self.assertEqual(result["finish"], 2)
        self.assertIsNone(result["deadline_gap"])
    def test_resource_conflict_not_silently_leveled(self):
        result = schedule.analyze(
            network([task("A", 2, resource="engineer"), task("B", 3, resource="engineer")])
        )
        self.assertEqual(result["finish"], 3)
        self.assertEqual(result["resource_conflicts"][0]["overlap_finish"], 2)
        self.assertIn("not resource-leveled", result["warnings"][0])
    def test_conflict_output_is_bounded(self):
        result = schedule.analyze(network([task(str(i), 1, resource="r") for i in range(20)]))
        self.assertEqual(result["resource_conflict_count"], 190)
        self.assertEqual(len(result["resource_conflicts"]), 100)
        self.assertTrue(result["resource_conflicts_truncated"])
    def test_adjacent_and_zero_duration_do_not_conflict(self):
        result = schedule.analyze(
            network(
                [
                    task("A", 2, resource="r"),
                    task("B", 1, ["A"], resource="r"),
                    task("M", 0, resource="r"),
                ]
            )
        )
        self.assertEqual(result["resource_conflicts"], [])
    def test_order_independence_and_no_input_mutation(self):
        original = copy.deepcopy(self.data)
        first = schedule.analyze(self.data)
        self.assertEqual(self.data, original)
        self.data["tasks"].reverse()
        self.assertEqual(first, schedule.analyze(self.data))
    def test_float_durations(self):
        result = schedule.analyze(network([task("A", 0.1), task("B", 0.2, ["A"])]))
        self.assertAlmostEqual(result["finish"], 0.3)
        self.assertEqual(result["critical_tasks"], ["A", "B"])
    def test_invalid_durations(self):
        for value in [-1, True, "2", None, float("nan"), float("inf"), 10**400]:
            with self.subTest(value=str(value)), self.assertRaises(ValueError):
                schedule.analyze(network([task("A", value)]))
    def test_graph_errors(self):
        for tasks in [
            [],
            [task("A", 1), task("A", 2)],
            [task("A", 1, ["missing"])],
            [task("A", 1, ["A"])],
            [task("A", 1, ["B"]), task("B", 1, ["A"])],
            [task("A", 1), task("B", 1, ["A", "A"])],
        ]:
            with self.subTest(tasks=tasks), self.assertRaises(ValueError):
                schedule.analyze(network(tasks))
    def test_unknown_fields_and_malformed_types(self):
        samples = [
            None,
            [],
            network([None]),
            network([task("", 1)]),
            network([task("A", 1)], unit="days"),
            network([task("A", 1)], schema_version=True),
            network([task("A", 1)], deadline=True),
            network([task("A", 1)], calendar="holiday"),
            network([task("A", 1, lag=2)]),
            network([task("A", 1, resource="")]),
        ]
        for data in samples:
            with self.subTest(data=data), self.assertRaises(ValueError):
                schedule.analyze(data)
    def test_bounds(self):
        for data in [
            network([task(str(i), 1) for i in range(501)]),
            network([task("A", 600000), task("B", 600000)]),
        ]:
            with self.assertRaises(ValueError):
                schedule.analyze(data)
    def test_cycle_dependent_on_valid_root(self):
        with self.assertRaisesRegex(ValueError, "cycle"):
            schedule.analyze(
                network([task("root", 1), task("A", 1, ["root", "B"]), task("B", 1, ["A"])])
            )
    def test_cli_success_errors_and_read_only(self):
        with tempfile.TemporaryDirectory() as folder:
            path = Path(folder) / "input.json"
            for content, code in [
                (json.dumps(self.data), 0),
                ('{"tasks":[],"tasks":[]}', 2),
                ('{"x": NaN}', 2),
                ("not json", 2),
                ("[" * 1500, 2),
                (" " * (schedule.MAX_BYTES + 1), 2),
            ]:
                path.write_text(content)
                result = subprocess.run(
                    [sys.executable, str(SCRIPT), "--input", str(path), "--json"],
                    capture_output=True,
                    text=True,
                    timeout=10,
                )
                self.assertEqual(result.returncode, code, result.stderr)
                self.assertEqual(path.read_text(), content)
                self.assertEqual(list(Path(folder).iterdir()), [path])
                if code == 0:
                    self.assertEqual(json.loads(result.stdout)["finish"], 6)
                    self.assertEqual(result.stderr, "")
                else:
                    self.assertEqual(result.stdout, "")
                    self.assertIn("error:", result.stderr)
    def test_missing_file(self):
        with tempfile.TemporaryDirectory() as folder:
            result = subprocess.run(
                [sys.executable, str(SCRIPT), "--input", str(Path(folder) / "absent")],
                capture_output=True,
                text=True,
                timeout=10,
            )
            self.assertEqual(result.returncode, 2)
            self.assertNotIn("Traceback", result.stderr)
 if __name__ == "__main__":
    unittest.main()
@@ -0,0 +1,26 @@
 # Approach decision
 Date / decision owner / state: [fill]
 Project evidence inspected: [sources and freshness]
 Current approach and what works: [preserve useful practices]
 Observed problem to solve: [specific evidence]
 | Condition | Evidence | Effect on choice |
 |---|---|---|
 | Requirement stability / technical uncertainty | [fill] | [fill] |
 | Incremental value / reversibility | [fill] | [fill] |
 | Capacity / interruptions / dependencies | [fill] | [fill] |
 | External deadlines / governance | [fill] | [fill] |
 Chosen approach: [name; explain fit]
 Nearest alternative and why not now: [reason]
 Adaptations: [practices changed and why; avoid claiming full framework compliance]
 | Workstream or decision | Method / cadence | Accountable owner | Handoff evidence |
 |---|---|---|---|
 | [fill] | [fill] | [accepted or proposed] | [fill] |
 Costs of change: [training, migration, meetings, disruption]
 First inspection: [date/event, evidence of improvement or harm]
 Revisit trigger: [observable condition that changes the choice]
 Approval / unresolved decisions: [authority and source]
@@ -0,0 +1,22 @@
 # Change or recovery decision
 ID / project / as-of / requested by: [fill]
 Current approved baseline: [version and evidence]
 Trigger: [new scope / defect / slipped forecast / failed dependency / other]
 Observed facts: [sources]
 Assumptions and disputed claims: [separate from facts]
 Remaining work and limiting condition: [evidence or gap]
 | Option | Scope / benefit | Schedule | Cost / capacity | Quality / risk | Dependencies / operations | Reversibility |
 |---|---|---|---|---|---|---|
 | Do nothing | [consequence] | [forecast] | [fill] | [fill] | [fill] | [fill] |
 | [reduce, resequence, stage, defer, stop, other] | [fill] | [conditional] | [fill] | [fill] | [fill] | [fill] |
 Recommended option and rationale: [fill]
 Authority / tolerance affected / decision deadline: [fill]
 Decision and evidence: [approved / rejected / pending; source]
 Residual risks and accepting authority: [fill]
 Updated baseline version if approved: [keep prior baseline]
 Affected owners notified: [actual evidence or prepared draft]
 Recovery verification checkpoint: [evidence, owner, date/event]
 Stop or escalation condition: [fill]
@@ -0,0 +1,19 @@
 # Project closure or pause
 Project / date / authority / decision: [complete / cancel / pause]
 Acceptance compared with approved scope: [criteria and evidence]
 Original commitment versus outcome: [variance and explanation]
 Release/operational readiness decision: [specialist record, separate from closure]
 | Residual obligation | Disposition | Accepted receiving owner | Capacity / funding | Due or review trigger | Evidence |
 |---|---|---|---|---|---|
 | [unfinished scope, support, defect, supplier] | [finish / transfer / cancel / accept] | [fill or gap] | [fill] | [fill] | [fill] |
 Operational handoff: [support, escalation, documentation, training, budget]
 Stabilization exit: [signals and owner]
 Financial commitments reconciled by: [owner/evidence]
 Benefit review: [expected outcome, measure, owner, review date/event]
 Lessons: [observed / inferred / proposed improvement]
 Record retention: [existing policy/location; no implicit deletion]
 Restart criteria if paused: [owner and trigger]
 Unresolved closure blockers: [explicitly list or none with evidence]
@@ -0,0 +1,18 @@
 # Dependency agreement
 ID / project / as-of: [fill]
 Provider and receiver: [teams and accepted owners]
 Deliverable and interface version: [specific usable output]
 Hard dependency or optional input: [what can proceed without it; what cannot]
 - Receiver acceptance criteria and verifier: [fill]
 - Needed-by date and consequence of delay: [fill]
 - Provider forecast and confidence basis: [fill]
 - Accepted commitment and source: [fill or explicitly uncommitted]
 - Integration checkpoint and evidence: [fill]
 - Required capacity / environment / procurement: [fill]
 - Change notification and acknowledgement: [owners and response window]
 - Escalation trigger, decision-maker, latest useful decision date: [fill]
 - Contingency and when it becomes unavailable: [fill]
 - Next review: [date/event]
 - Actual delivery and receiver acceptance: [separate evidence]
@@ -0,0 +1,33 @@
 # Project brief
 Project: [name] · As of: [date] · State: [proposed / authorized / paused / closed]
 Authoritative records: [links and versions]
 ## Outcome and authority
 - Why this project exists: [problem/outcome]
 - Success and acceptance evidence: [observable criteria, evaluator]
 - Sponsor / funding authority: [accepted role/person]
 - Delivery coordinator: [accepted owner and delegated decisions]
 - Technical, product, and risk decisions: [respective authorities]
 - Scope included / excluded: [boundaries]
 - Approval record or missing authorization: [source; do not infer approval]
 ## Constraints and assumptions
 | Constraint | Hard or negotiable? | Source | Consequence / decision owner |
 |---|---|---|---|
 | [date, budget, quality, capacity, obligation] | [classification] | [evidence] | [effect] |
 Capacity: [availability by capability; operations, leave and part-time constraints]
 Dependencies: [link to existing plan and critical handoffs]
 Uncertainty: [known gaps, validation owner, next learning decision]
 ## Working agreement
 Selected approach and rationale: [link to approach decision if needed]
 Source of truth: [where scope, milestones, decisions and evidence live]
 Review rhythm: [smallest useful cadence; audience; decision purpose]
 Escalation triggers and authority: [agreed tolerances, not invented percentages]
 Next milestone: [acceptance evidence, forecast, commitment if accepted]
 Next action or decision: [owner acceptance or explicit gap; due/review trigger]
@@ -0,0 +1,31 @@
 # Project control record
 Project / as-of date / maintainer: [fill]
 Authoritative baseline version and approval: [fill]
 Agreed tolerances and health criteria: [fill]
 ## Milestones
 | ID | Accepted outcome | Owner | Baseline | Current forecast and basis | Required deadline | Actual acceptance evidence | Health |
 |---|---|---|---|---|---|---|---|
 | M1 | [criterion] | [accepted/gap] | [date] | [range, assumptions] | [date/source] | [link or missing] | [on track / at risk / off track / unknown] |
 ## Risks, issues, and assumptions
 | ID / type | Description and evidence | Impact | Owner | Signal / expiry | Mitigation or resolution | Contingency | Review / due | State |
 |---|---|---|---|---|---|---|---|---|
 | [risk/issue/assumption] | [fact vs inference] | [affected outcome] | [accepted/gap] | [trigger] | [action] | [fallback] | [date/event] | [fill] |
 Materialized risks link to issue records: [IDs]
 Critical dependencies: [links to dependency agreements and current gaps]
 Capacity exceptions: [shared specialists, leave, interruptions; impact]
 Cost exposure: [approved funding, actuals, outstanding commitments, remaining estimate,
 contingency and reconciliation basis; unknowns explicitly identified]
 ## Decisions and changes
 | ID | Decision needed / made | Options and consequence of waiting | Authority | Latest useful decision date | Rationale / source | Affected baseline |
 |---|---|---|---|---|---|---|
 | D1 | [fill] | [fill] | [fill] | [date/basis] | [pending or evidence] | [version] |
 Next review and required evidence: [fill]
@@ -0,0 +1,11 @@
 {
  "schema_version": 1,
  "unit": "working_days",
  "deadline": 5,
  "tasks": [
    {"id": "design", "duration": 2, "depends_on": []},
    {"id": "build", "duration": 3, "depends_on": ["design"], "resource": "specialist"},
    {"id": "review-prep", "duration": 1, "depends_on": ["design"], "resource": "specialist"},
    {"id": "accept", "duration": 1, "depends_on": ["build", "review-prep"]}
  ]
 }
@@ -0,0 +1,20 @@
 # Project status and decision brief
 Project / audience / as-of / baseline version: [fill]
 Draft or issued: [state; issuing needs authorization]
 **Assessment:** [health by material dimension; unknowns visible]
 **Changed since last review:** [evidence-backed delta]
 **Impact:** [outcome, forecast, cost, quality, dependencies]
 **Recommendation:** [specific option and why]
 **Decision needed:** [authority, latest useful date and consequence of delay]
 | Option | Outcome / scope | Date forecast and assumptions | Cost / capacity | Risk / quality | Affected parties |
 |---|---|---|---|---|---|
 | [fill] | [fill] | [fill] | [fill] | [fill] | [fill] |
 Accepted progress: [links to evidence]
 Baseline commitment versus current forecast: [separate values]
 Top blocker / risk / uncertainty: [owner and response]
 Next evidence checkpoint: [owner, date/event, artifact]
 Supporting record: [link; avoid duplicating the tracker]