@windyroad/itil 3.4.0-preview.1368 → 3.4.0-preview.1370

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@windyroad/itil",
-  "version": "3.4.0-preview.1368",
+  "version": "3.4.0-preview.1370",
   "description": "ITIL-aligned IT service management for Claude Code and Codex",
   "bin": {
     "windyroad-itil": "./bin/install.mjs"

package/skills/outcome-led-planning/SKILL.md

@@ -16,7 +16,7 @@ Read the relevant current evidence, project instructions, decisions, jobs, risk
 
 Use SMART to make the objective specific, measurable through observable completion evidence, achievable against known constraints, relevant to the user's job, and time-bound using the user's stated deadline or timeframe. Qualitative evidence can establish success. Surface feasibility uncertainty instead of weakening the objective or promising certainty. Never invent numerical targets or dates. Preserve stated timing and prefer relative wording. Any added date must match verified context and its weekday. Never turn a guessed date into a new timing interview. If neither a time bound nor an explicit decision to omit one is established, ask one timing question and wait. If the user declines a time bound, record the exception honestly rather than claiming full SMART compliance.
 
-If intent is unclear or information is missing, interview the user: **ask one focused question, then stop and wait for their answer before asking the next**. Select the next question from their actual answer and remaining uncertainty. Do not bundle questions, answer on their behalf, invent their intent, or resolve ambiguity by selecting a solution. Bounded read-only investigation can establish facts within existing authority.
+If outcome information is unclear or missing, interview the user: **ask one focused question, then stop and wait for their answer before asking the next**. Select the next question from their actual answer and remaining uncertainty. Do not bundle questions, answer on their behalf, invent their intent, or resolve ambiguity by selecting a solution. Bounded read-only investigation can establish facts within existing authority.
 
 One question requests **one missing fact**. Do not combine multiple information needs, such as who benefits and what is wrong, into a multipart question. Sharing a topic or using one question mark does not make it one question.
 
@@ -104,6 +104,6 @@ Finish when the objective's completion evidence is satisfied. Record the verifie
 
 Recording verified completion is a terminal status update, not another executable plan. Any newly proposed work still needs its own assessed plan.
 
-If blocked, first exhaust useful authorized steps available to the agent. Preserve work, distinguish completed increments from unfinished outcomes, and report the precise missing evidence, capability, authority, or irreducible user action. Resume from fresh evidence when the blocker clears; do not restart completed effects.
+Before handing back a blocker, finish useful authorized work, including running checks. Preserve work, distinguish completed increments from unfinished outcomes, and report the precise missing result, capability, authority or irreducible user action. Resume from fresh evidence when the blocker clears; do not restart completed effects.
 
 Communicate the objective, consequential plan changes, decisions requiring input, exact blockers, and verified outcomes concisely. Avoid narrating routine commands or every review and wait.

package/skills/outcome-led-planning/references/github-coordination.md

@@ -128,21 +128,62 @@ Give the existing planning critic the saved outcome and affected increment recor
 
 **Horizon belongs only to increments**: each planned or active increment has exactly one of Now, Next or Later. Remove completed or superseded increments from active horizons while preserving their prior position in history. **Status** separately describes execution, such as ready, in progress, blocked or done. A blocked Now increment does not automatically become Next; a completed task does not become a completed outcome. Outcomes and tasks do not inherit Horizon. Map these meanings to existing repository labels or Project fields. Replace the previous horizon when replanning rather than accumulating contradictory values.
 
-Use and verify native sub-issue relationships when supported; otherwise record explicit reciprocal parent/child links, read back both affected issue bodies and disclose the limitation. When another task supplies a required result, **create and verify its native blocked-by dependency** whenever the available API and permissions support it. Record real prerequisites even when they constrain a later stage or task completion rather than the next useful step. Name the precise start, stage or completion unlock condition and required evidence. Do not require administrative issue closure in addition to the verified result unless recorded acceptance or an applicable project rule requires it. A Ready or In progress task may retain open dependencies while useful preparation proceeds; those dependencies still gate the dependent stage or completion. Never remove a real dependency merely to make preparation available. If the native capability is unavailable or denied, record the exact limitation and reciprocal dependency links, read back both affected issue bodies. Native write denial establishes neither presence nor absence of existing links; preserve known links and report unreadable native state as unknown. Optional Project membership and fields mirror issue state; do not create a Project or fields merely because the protocol mentions them.
-
-Keep completion dependencies acyclic. A prerequisite task cannot also require its dependent's result to close. Propose corrections in the increment thread; the increment owner records revised task boundaries and acceptance with affected task owners before applying them. Obtain the five independent plan reviews before executing a materially revised plan. Give each task an independently verifiable result and retain the combined results in increment acceptance. Reassess the dependent task when a prerequisite is satisfied; independently verify its evidence before clearing that condition.
+Maintain parent/child and prerequisite relationships in this order:
+
+1. Inspect the actual relationship and the precise result that unlocks a start,
+   stage or completion. Read current native sub-issue and blocked-by state when
+   supported. A native write denial proves neither presence nor absence:
+   preserve known links and keep unreadable native state unknown.
+2. Keep completion dependencies acyclic. A prerequisite cannot require its
+   dependent's result to close. Propose changed task boundaries and acceptance
+   in the increment thread; the increment owner records agreement with affected
+   task owners before applying them. Obtain the five independent reviews before
+   materially revised execution. Give each task an independently verifiable
+   result and retain the combined results in increment acceptance.
+3. After any required agreement and reviews, use native links when supported;
+   create a missing required link or update a changed one when authorized.
+   Verify saved native state and both relationship directions. If operations are
+   unavailable, record their exact limitation plus reciprocal parent/child or
+   prerequisite/dependent text links on both affected issues; text is not proof
+   of native state. Request capable help through an authorized channel when
+   useful, without inventing a helper or widening access.
+4. Reassess actual useful work and status under the claim table below. A Ready
+   or In progress task may prepare while a real prerequisite remains open;
+   preserve its precise unlock condition and required evidence. Independently
+   verify the prerequisite result before clearing that condition and proceeding
+   with the dependent stage. Administrative issue closure is not another
+   prerequisite unless recorded acceptance or a project rule requires it.
+
+Optional Project membership and fields mirror issue state; do not create them
+merely because this protocol mentions them.
 
 Replan task boundaries at any stage when evidence changes what work is needed. Coordinate narrowed, split, replaced or dropped scope with the increment owner and affected task owners. Close redundant or superseded issues as **not planned**, with the reason and successor links; never mark undelivered work Done merely to retire it. Before removing a dependency, move still-required acceptance evidence to the appropriate task and retain it in increment acceptance. Remove only genuinely obsolete native dependencies and verify the saved result; preserve prerequisites that still constrain the revised work. Keep task briefs, links, ownership and any selected Project fields current. Routine task reconciliation within the assessed outcome and authority needs no new user approval; materially revised executable work still requires the five independent plan reviews.
 
-Reassess scope, available inputs and useful authorized next steps before deciding that a claimed task is blocked. A stored Blocked status alone does not establish exhaustion; when it is unknown, investigate or state the condition. Required watcher duties count as useful work. Apply these linked decisions to the current claim, finishing when recorded acceptance is met:
+### Status and contribution-claim decision
+
+Use this table whenever work starts, blocks, finishes or is handed over. Inspect
+scope, inputs and actual useful authorized in-task steps first: a stored Blocked
+status alone does not establish exhaustion. Genuine assigned watcher duties
+count as useful work; waiting for an unverified response or routine discussion
+reads alone do not retain an exhausted implementation reservation.
 
-| Actual state of the claimed task | Status | Claim action |
+| Actual state of the claimed task | Status | Assignment and saved result |
 | --- | --- | --- |
-| Recorded acceptance is verified with evidence | Done | Finish with evidence; preserve attribution history. |
+| Recorded acceptance is verified with evidence | Done | Post acceptance evidence, finish and preserve attribution history. |
 | Useful authorized in-task work remains | In progress | Retain the single claim and do that work. |
-| A required input is unavailable and no useful authorized in-task step remains | Blocked | Record the blocker, evidence, unlock condition and handover; remove your assignment and read back its removal. Preserve historical attribution. |
+| A required input is unavailable and no useful authorized in-task step remains | Blocked | Save the blocker, evidence, unlock condition and handover; remove your assignment and read back its removal. Preserve historical attribution. |
 
-Keep independently actionable unclaimed work Ready/Unclaimed. Preserve real prerequisites before their dependent stage; never invent busywork to avoid Blocked. Reassess when evidence changes. A blocked task does not block every contribution. If assignment mutation or verification is unavailable, record the exact pending release and current known claim state, use an authorized owner/channel when available, and do not claim an unverified release or take another task while still assigned.
+One contribution claim is a ceiling, not a retention requirement. A blocked
+assignment still counts until release is verified. Apply the table before
+claiming another task; never reserve queued tasks. Outcome/increment ownership
+does not reserve contributions. Agents sharing an account remain distinct by
+their recorded agent/session. Keep actionable unclaimed work Ready/Unclaimed;
+a blocked task does not block every contribution. Never invent busywork.
+
+If assignment mutation or verification is unavailable, record the exact pending
+release and known claim state, use an authorized owner/channel when available,
+and do not claim release or take another task while still assigned. Reassess
+when evidence changes.
 
 ## Join, claim and contribute
 
@@ -151,71 +192,81 @@ Use this contribution lifecycle:
 1. Read the outcome, current Now revision, discussion, dependencies and claims. Reconcile stale scope before dependent work.
 2. Choose a bounded useful result and announce its acceptance and file/operation boundary in the increment thread. Resolve overlap, shared operations or authority questions with affected owners. A non-overlapping task within the assessed Now needs no allocator approval.
 3. Reuse a matching unclaimed task, or create your own just before work. Apply the established task-kind marker (`kind:task` by default). Assign it to the **actual authenticated account** and record the **specific agent/session** and native links; read back kind, assignment, claim and links and recheck competing work. For a selected or required Project, explicitly add the task and read back its membership and applicable fields so it matches the saved view.
-4. Execute within the assessed plan and authority, keeping status and evidence current. Finish with verified evidence or release with a handover stating evidence, blocker and next step.
+4. Execute within the assessed plan and authority; apply the status and contribution-claim decision above, including saved release when exhausted.
 5. Choose and document the next useful contribution from the remaining outcome gap, then repeat these checks before claiming it.
 
 A starting battle plan exposes likely work, dependencies and parallel opportunities without precreating, assigning or reserving every future task. The increment owner keeps acceptance, sequence and integration clear and resolves overlap/dependencies. Explicit assignments and handoffs remain valid. Two agents sharing an account are distinct contributors. Checklists suffice for routine steps; do not create a task for every command. Task creation within assessed scope requires no fresh human approval.
 
-**Each agent holds only one contribution task at a time**, including a blocked assignment. Finish, explicitly hand over or release the current assignment before claiming another. Do not reserve queued tasks. Outcome or increment coordination ownership does not reserve contribution tasks. Agents sharing an account remain distinct through their recorded agent/session identities.
-
 Before declaring a contribution ready to start, complete this claim receipt: **no other contribution assignment held; parent increment; current assessed plan revision; non-overlapping scope; dependencies (or explicitly none); actual account; distinct agent/session; saved claim and reciprocal-link readback; competing-claim recheck.** Record all fields on the task, even when some are already known in conversation. Assignment does not increase authority. When explaining a proposed claim, make these required fields and the before/after overlap checks explicit.
 
 Record scope boundaries and dependencies, then read back the claim, links and any competing claims. Issue claims are cooperative, not atomic locks: another agent may have claimed overlapping work since your first read. Reconcile that race before dependent implementation. If another contributor has claimed the same work, agree a split or handoff in the increment thread before overlapping implementation. An inactive or old claim is not permission to take over silently. If assignment is unavailable, record the intended owner and unassigned state, request the owner’s help through the agreed coordination channel when authorized, and continue only work whose ownership is clear. Never claim an assignment or board update succeeded without reading it back.
 
 ## Reconcile tracking at work checkpoints
 
-Use **two complementary discussion checks**:
-
-1. **Throughout active work:** read new increment comments regularly between
-   bounded work cycles while coding or waiting, following the agreed, recorded
-   cadence. Until agreement exists, continue already-authorized regular bounded
-   reads; proposing a cadence does not replace those reads.
-2. **At events:** check on joining or resuming and again at the checkpoints below,
-   including before dependent actions, pushes, scope/ownership changes and handovers.
-   Neither duty replaces the other: regular-only and checkpoint-only reads
-   are both incomplete.
-
-Propose an appropriate bounded cadence through the authorized increment thread,
-obtain agreement and verify its saved record before calling it agreed. A suggested
-interval alone is not an agreement. Record pending agreement honestly without
-suspending either kind of check. These are checks during an active work window,
-not a standing poller or a promise to wake an idle agent.
-
-Read relevant new comments, acknowledge handoffs and answer questions affecting
-your work through already-authorized channels. Keep task records current with
-the resulting evidence or changes. A posted message is not the recipient's
-actual acknowledgement.
+During an active work window, follow this coordination sequence while coding
+or waiting:
+
+1. Use the agreed, saved discussion-reading cadence. If none exists, propose a
+   bounded cadence through the authorized increment thread, obtain agreement
+   and verify its saved record. While agreement is pending, continue regular
+   bounded reads; a proposal is not agreement.
+2. Also read new increment comments on joining/resuming and at the event
+   checkpoints below, including before dependent actions, pushes, scope or
+   ownership changes and handovers. Regular reads and event reads are both
+   required; neither replaces the other.
+3. Answer relevant questions and handle handoffs through the authorized channel
+   and handoff rules below: actual recipient
+   acknowledgement and linked task, independent verification of returned
+   evidence, and updates to your task's evidence, dependency and next action.
+   A posted message is not the recipient's acknowledgement.
+4. If the result materially changes the executable plan, reconcile that revision
+   and obtain the five independent reviews before dependent execution. Otherwise
+   continue within the assessed plan. Apply the claim table when work is
+   exhausted rather than retaining it for discussion reads.
+
+These are bounded checks during active work, not a standing poller or a promise
+to wake an idle agent. Use only already-authorized communication channels.
 
 At each work checkpoint, reconcile tracking in this order:
 
-For a join/resume checkpoint with a selected Project and working `gh`, MUST use
-the [executable Project checkpoint](github-project-checkpoint.md). Read its
-inspection and handle current discussion before applying it; do not manually
-publish synchronization-success text on that route. Other checkpoints and
-authorized alternatives retain the rules below.
-
-1. **Establish scope.** Reuse the established backend. Establish Project selection
-   separately from the backend, using configuration, project requirements or
-   explicit direction: selected/required, none, or unresolved. Do not infer none
-   or an unset configuration from omitted information. An established choice to
-   use no Project needs no setup. While selection remains unresolved, inspect available
-   records and keep Project work conditional; do not assert a pending or
-   unsynchronized mirror. An unavailable API or bootstrap default proves neither
-   selection nor a missing view, field or membership; inspect saved setup before
-   naming gaps.
-2. **Inspect each affected record.** Read each outcome, increment and task
-   against the minimum-information table above. Preserve its own owner/account,
-   applicable agent/session, revision and acceptance; mark missing required
-   information unresolved. Record current scope, actual status, increment-only
-   Horizon, dependencies or blocker, next action and state-appropriate evidence.
-   Preserve completed tasks' recorded revisions and acceptance criteria;
-   completion evidence does not replace either. A provisional increment retains
-   its recorded owner, brief revision and tentative acceptance, marking missing
-   values unresolved. These do not imply an executable plan, critic approval or
-   completion evidence.
-   For a selected or required Project, Status reflects actual work and Agent
-   belongs to that item's verified owner/session: never copy the task contributor
-   upward or replace another owner's identity.
+When the affected records include an outcome, current Now, provisional Next and
+a task, and `gh` works, MUST first use the [read-only hierarchy inspector](github-project-checkpoint.md#inspect-the-hierarchy).
+Construct its request from those actual records and consume its findings before
+claiming completeness; identical draft/remote text is not that comparison.
+Do not manufacture a Next issue for this route. Its configuration report is one
+source for the selection decision below, not proof of capability or acceptance.
+
+1. **Establish selection before checking Project capability.** Reuse the
+   established backend. From configuration, project requirements or explicit
+   direction, choose the applicable branch:
+   - **Selected/required:** verify the repository, Project and account, then
+     inspect its saved setup and applicable operations. For join/resume of an
+     active open task with working `gh`, MUST use the [executable Project checkpoint](github-project-checkpoint.md).
+     Read its inspection and handle current discussion before applying it;
+     do not manually publish synchronization-success text on that route.
+     If an applicable operation is unavailable, retain its exact pending state
+     under the recovery rules below. An unavailable API or bootstrap default
+     does not prove a missing view, field or membership.
+   - **Established none:** continue issue-side reconciliation without Project
+     setup, fields or synchronization.
+   - **Unresolved:** inspect available configuration, requirements, direction and
+     issue records. Record the selection gap and keep Project work conditional;
+     there is no established mirror operation to report pending or unsynchronized.
+     Omitted information and API availability establish neither selection nor
+     an explicit choice to use no Project.
+2. **Inspect each affected record before classifying it.** Compare every
+   outcome, increment and task with the minimum-information table. Preserve its
+   own recorded owner/account, applicable agent/session, revision and acceptance,
+   including provisional and completed records. Mark a required value unresolved
+   only when inspection cannot establish it; omission from a scenario or summary
+   does not establish that saved information is missing. Completion evidence
+   does not replace the task's own revision or acceptance. Provisional ownership,
+   revision and tentative acceptance imply neither an executable plan nor
+   critic approval or completion evidence.
+   Record actual scope, status, increment-only Horizon, dependencies/blocker,
+   next action and state-appropriate evidence. For a selected/required Project,
+   each item's Agent remains its verified owner/session, never an identity
+   copied from its parent or child; Status reflects that item's actual work.
 3. **Update and verify.** Make only necessary authorized changes to existing
    records. Read back every changed issue's fields and links, checking both
    directions of parent/dependency relationships. For a selected or required
@@ -235,7 +286,7 @@ system.
 | Join, resume or start implementation | Read current records and discussion; correct stale status, scope and ownership before dependent implementation. Set the active task and increment In progress when useful work starts. Complete missing selected Project setup or record its precise unavailable operation. |
 | Material milestone or failed verification | Record the actual result and evidence before the next dependent action. Keep In progress while useful repair remains; a failed check alone does not mean Blocked. |
 | Scope, dependency, plan or horizon change | Update affected briefs, native relationships and increment horizons; remove superseded active horizons. Obtain the required reviews before materially revised execution. |
-| Block, hand off, finish or yield the active work window | Record the exact remaining gap, next action and owner, or acceptance evidence for completion. Reconcile the increment as well as the task; do not leave an old Todo/Ready or stale next action for someone else to discover. |
+| Block, hand off, finish or yield the active work window | Apply the claim table, saving the gap, next action/owner or acceptance evidence and verifying any required release. Reconcile the increment as well as the task; do not leave stale status or next action. |
 
 For a selected or required Project, when an operation is unavailable, record
 the affected view/field/item,
@@ -271,7 +322,7 @@ When an authorized owner must complete a pending Project operation, request it t
 
 ## Verify, learn and replan as the outcome owner
 
-Post acceptance evidence before completing a task. Preserve its actual recorded acceptance: do not invent a later release check as a repair-task completion condition, or remove an established condition to finish early. At handoff, state one coherent claim transition: retain it while useful authorized work remains within its scope, finish when acceptance is met, release it unassigned with the remaining gap, or transfer to an identified owner after acknowledgement. Do not report both releasing and retaining the same claim. The increment owner verifies the whole increment against its criteria before closing it; task completion alone does not establish delivery. Publication, installed behavior and production/customer verification remain separate evidence stages where applicable.
+Post acceptance evidence before completing a task. Preserve its actual recorded acceptance: do not invent a later release check as a repair-task completion condition, or remove an established condition to finish early. At handoff, apply the claim table; an explicit ownership transfer additionally needs the identified recipient's acknowledgement. Do not report both releasing and retaining the same claim. The increment owner verifies the whole increment against its criteria before closing it; task completion alone does not establish delivery. Publication, installed behavior and production/customer verification remain separate evidence stages where applicable.
 
 After a verified increment, or earlier when evidence invalidates the plan, the outcome owner:
 

package/skills/outcome-led-planning/references/github-project-checkpoint.md

@@ -1,6 +1,72 @@
-# Execute a selected-Project resume checkpoint
+# Inspect and reconcile GitHub records
 
-For a join/resume checkpoint with a selected GitHub Project and working `gh`,
+Resolve `scripts/github-project-checkpoint.mjs` relative to this installed
+planning skill, including when called from `contribute`. Use the existing
+authenticated `gh` account and saved project configuration. The default is
+`.agents/planning.json`; an existing project-declared configuration path may be
+supplied last. These operations require no new grants, account changes or tokens.
+Local tracking keeps its existing path.
+
+## Inspect the hierarchy
+
+When reconciling an outcome, current Now, an affected provisional Next and a
+task together with working `gh`, planning and `contribute` MUST first use the
+read-only hierarchy inspector. Supply those actual distinct issue numbers;
+do not invent a Next issue to satisfy the command. Other record sets retain
+their existing coordination path.
+
+```json
+{
+  "outcome": 1,
+  "increment": {"issue": 2},
+  "next": {"issue": 3},
+  "task": {"issue": 4}
+}
+```
+
+Run `node <installed-planning-skill>/scripts/github-project-checkpoint.mjs inspect-hierarchy request.json`.
+This reads the four actual issues and their returned comments. It writes
+nothing and makes no Project or native-link request. Read the raw records and
+consume `findings` before claiming that the records are correct:
+
+- `projectSelection` reports configuration facts. `not-recorded` means selection
+  is unresolved from that configuration, not an explicit choice to use no
+  Project. `recorded` does not prove capability; consider actual project
+  requirements and explicit direction too. Preserve invalid configuration.
+- Each record's `inspection` reports literal owner, revision, acceptance and
+  Parent candidates with raw line evidence. `candidate` is text, not verified
+  ownership or passed acceptance. `explicitly-unresolved` preserves a recorded
+  unknown. Empty/missing literals, unsupported syntax and multiple candidates
+  remain unestablished by this inspector; they do not prove semantic information
+  is absent or that the issue is invalid. Inspect the actual prose/history
+  rather than forcing a new format or choosing a historical value.
+- `textLinks` compares the three requested textual relationships. A mention is
+  observed text, not proof of a current native relationship. Inspect both sides
+  and repair known reciprocal gaps under the existing coordination rules.
+- `capabilities` are `not-probed`; do not turn that into an outage or native-link
+  absence. `inspection-unavailable` means the read/report operation failed,
+  not that a Project mirror is pending.
+
+A successful command produces a diagnostic report, never a correctness or
+synchronization verdict. Identical drafts and saved bodies do not establish
+completeness. Before claiming completeness, account for every finding through
+actual semantic review, authorized repair with saved readback where needed, or
+honest unresolved recording in the existing plan or record. Follow the selection
+finding's conditional next action, which targets the existing outcome issue
+for saving and reading back a still-unresolved gap. Reuse an already saved gap
+without an unchanged write. Configuration alone may leave the choice unresolved
+while requirements or explicit direction establish it. Unsupported
+syntax does not force normalization or another artifact.
+Apply the existing per-record rules to known gaps, marking missing
+required information unresolved rather than inventing it; preserve completed
+acceptance and attribution. Read back authorized changes and compare reciprocal
+links before reporting reconciliation. Unsupported syntax needs actual review,
+not automatic normalization. Semantic acceptance remains with the caller and
+required independent review.
+
+## Synchronize selected Project fields
+
+For a join/resume checkpoint on an active open task with a selected GitHub Project and working `gh`,
 planning and `contribute` MUST use the bundled
 `scripts/github-project-checkpoint.mjs` operation. Do not manually publish a
 Project synchronization-success claim on this route. The operation reads the
@@ -8,10 +74,8 @@ records/discussion, updates the two items, verifies their saved fields and only
 then generates the task's synchronization result. It does not allocate owners,
 approve a plan, acknowledge another person or complete the increment.
 
-Resolve the script relative to this installed planning skill, including when
-called from `contribute`. Use the existing authenticated `gh` account and saved
-project configuration; no new grants, account changes or tokens are required by
-the operation. Local and GitHub Issues-only tracking keep their existing paths.
+This mutation route applies to its open outcome, increment and active task.
+GitHub Issues-only tracking uses no Project field mutations.
 
 ## Inspect, decide, apply
 

package/skills/outcome-led-planning/scripts/github-project-checkpoint.mjs

@@ -26,10 +26,14 @@ function json(args, input) {
   if (value.errors?.length) throw new Error(value.errors.map(error => error.message).join('; '));
   return value;
 }
-function scope(request, config) {
-  requireValue(config.version === 1 && config.backend === 'github', 'This operation requires the saved GitHub backend.');
+function repositoryFor(config) {
+  requireValue(config?.version === 1 && config.backend === 'github', 'This operation requires the saved GitHub backend.');
   const repository = config.github?.repository;
-  requireValue(typeof repository === 'string' && /^[\w.-]+\/[\w.-]+$/.test(repository), 'Invalid configured GitHub repository.');
+  requireValue(typeof repository === 'string' && /^[A-Za-z0-9](?:[A-Za-z0-9-]*[A-Za-z0-9])?\/[\w.-]+$/.test(repository) && !['.', '..'].includes(repository.split('/')[1]), 'Invalid configured GitHub repository.');
+  return repository;
+}
+function scope(request, config) {
+  const repository = repositoryFor(config);
   const url = new URL(config.github?.projectUrl);
   const match = url.pathname.match(/^\/(?:users|orgs)\/([\w.-]+)\/projects\/([1-9]\d*)(?:\/views\/[1-9]\d*)?\/?$/);
   requireValue(url.protocol === 'https:' && url.hostname === 'github.com' && match && !url.username && !url.password, 'A selected GitHub Project URL is required.');
@@ -44,6 +48,66 @@ function scope(request, config) {
 function issue(number, bound) {
   return json(['issue', 'view', String(number), '--repo', bound.repository, '--json', 'number,url,body,state,assignees,labels,comments']);
 }
+function briefField(body, pattern, cue) {
+  // shortcut: observed literal brief fields only; extend when an actual brief needs another syntax.
+  const lines = body.split(/\r?\n/).map((text, index) => ({ line: index + 1, text }));
+  const matches = lines.flatMap(line => {
+    const match = line.text.match(pattern);
+    return match ? [{ ...line, value: match[1].trim() }] : [];
+  });
+  const literalEvidence = matches.map(({ line, text }) => ({ line, text }));
+  if (matches.length > 1) return { state: 'multiple-candidates', evidence: literalEvidence };
+  if (matches.length === 1) {
+    const { value } = matches[0];
+    return { state: !value ? 'empty' : /^(?:unresolved|unknown|tbd|unclaimed)(?:\b|$)/i.test(value) ? 'explicitly-unresolved' : 'candidate', value, evidence: literalEvidence };
+  }
+  const evidence = lines.filter(line => cue.test(line.text));
+  return { state: evidence.length ? 'unsupported-format' : 'literal-field-missing', evidence };
+}
+function textReference(body, number, repository) {
+  const escaped = repository.replace(/[.*+?^${}()|[\]\\]/g, '\\$&');
+  const reference = new RegExp(`(?:(?<![\\w./#:-])#${number}\\b|https://github\\.com/${escaped}/issues/${number}(?![\\w/]))`, 'i');
+  const evidence = body.split(/\r?\n/).flatMap((text, index) => reference.test(text) ? [{ line: index + 1, text }] : []);
+  return { observed: evidence.length > 0, evidence };
+}
+function inspectHierarchy(request, config) {
+  const repository = repositoryFor(config);
+  const roles = { outcome: request?.outcome, increment: request?.increment?.issue, next: request?.next?.issue, task: request?.task?.issue };
+  requireValue(Object.values(roles).every(n => Number.isSafeInteger(n) && n > 0) && new Set(Object.values(roles)).size === 4, 'Four distinct outcome, increment, next and task issue numbers are required.');
+  const projectSelection = { state: 'not-recorded', source: 'configuration' };
+  if (Object.hasOwn(config.github, 'projectUrl')) {
+    try {
+      const url = new URL(config.github.projectUrl);
+      requireValue(url.protocol === 'https:' && url.hostname === 'github.com' && !url.username && !url.password && !url.search && !url.hash && /^\/(?:users|orgs)\/[\w.-]+\/projects\/[1-9]\d*(?:\/views\/[1-9]\d*)?\/?$/.test(url.pathname), 'Invalid recorded Project URL.');
+      Object.assign(projectSelection, { state: 'recorded', url: `https://github.com${url.pathname.split('/views/')[0].replace(/\/$/, '')}` });
+    } catch { projectSelection.state = 'invalid'; }
+  }
+  const records = {};
+  const findings = projectSelection.state === 'recorded' ? [] : [{ issue: roles.outcome, field: 'projectSelection', state: projectSelection.state, nextAction: `Establish selection from applicable project requirements and explicit direction. If it remains unresolved, save that selection gap and conditional Project work on outcome #${roles.outcome} and read back its saved body before claiming reconciliation complete. Reuse an already saved gap without an unchanged write.` }];
+  for (const [role, number] of Object.entries(roles)) {
+    const record = issue(number, { repository });
+    requireValue(record.number === number && record.url?.toLowerCase() === `https://github.com/${repository}/issues/${number}`.toLowerCase() && typeof record.body === 'string', 'Returned issue does not match its requested repository/number or brief.');
+    const inspection = {
+      owner: briefField(record.body, /^\s*(?:(?:Outcome|Increment|Task) )?Owner:\s*(.*)$/i, /\bowner\b/i),
+      revision: briefField(record.body, /^\s*Revision:\s*(.*)$/i, /\brevision\b/i),
+      acceptance: briefField(record.body, /^\s*(?:Tentative )?Acceptance(?: criteria| evidence)?:\s*(.*)$/i, /\bacceptance\b/i),
+      parent: briefField(record.body, /^\s*Parent(?: outcome| increment)?:\s*(.*)$/i, /\bparent\b/i)
+    };
+    records[role] = { ...record, inspection };
+    for (const field of ['owner', 'revision', 'acceptance']) {
+      if (!['candidate', 'explicitly-unresolved'].includes(inspection[field].state)) findings.push({ issue: number, field, state: inspection[field].state });
+    }
+  }
+  const textLinks = [[records.outcome, records.increment], [records.outcome, records.next], [records.increment, records.task]].map(([parent, child]) => {
+    const parentMentionsChild = textReference(parent.body, child.number, repository);
+    const field = child.inspection.parent;
+    const referencesExpected = 'value' in field ? textReference(field.value, parent.number, repository).observed : null;
+    if (!parentMentionsChild.observed) findings.push({ issue: parent.number, field: 'child-text-reference', state: 'not-established', child: child.number });
+    if (referencesExpected !== true) findings.push({ issue: child.number, field: 'parent-text-reference', state: 'not-established', parent: parent.number });
+    return { parent: parent.number, child: child.number, parentMentionsChild, childParent: { ...field, referencesExpected } };
+  });
+  return { repository, projectSelection, capabilities: { project: 'not-probed', nativeLinks: 'not-probed' }, records, textLinks, findings };
+}
 function items(request, bound, projectId) {
   const response = json(['api', 'graphql', '--input', '-'], JSON.stringify({ query: itemQuery, variables: { ids: [request.increment.itemId, request.task.itemId], agentFieldId: request.agentFieldId } }));
   requireValue(response.data.agentField?.dataType === 'TEXT', 'The Agent field must be a text field.');
@@ -125,18 +189,20 @@ function apply(request, inspection, config) {
 }
 
 if (process.argv[2] === '--help') {
-  console.log('Inspect: node github-project-checkpoint.mjs inspect REQUEST.json [CONFIG.json]\nApply: node github-project-checkpoint.mjs apply REQUEST.json INSPECTION.json [CONFIG.json]');
+  console.log('Hierarchy: node github-project-checkpoint.mjs inspect-hierarchy REQUEST.json [CONFIG.json]\nInspect: node github-project-checkpoint.mjs inspect REQUEST.json [CONFIG.json]\nApply: node github-project-checkpoint.mjs apply REQUEST.json INSPECTION.json [CONFIG.json]');
 } else {
   try {
     const [mode, requestPath, third, fourth] = process.argv.slice(2);
-    requireValue(mode === 'inspect' || mode === 'apply', 'Expected inspect or apply; use --help for usage.');
+    requireValue(['inspect', 'apply', 'inspect-hierarchy'].includes(mode), 'Expected inspect-hierarchy, inspect or apply; use --help for usage.');
     const request = load(requestPath);
-    const config = load((mode === 'inspect' ? third : fourth) || '.agents/planning.json');
-    const result = mode === 'inspect' ? inspect(request, config) : apply(request, load(third), config);
+    const config = load((mode === 'apply' ? fourth : third) || '.agents/planning.json');
+    const result = mode === 'inspect-hierarchy' ? inspectHierarchy(request, config) : mode === 'inspect' ? inspect(request, config) : apply(request, load(third), config);
     console.log(JSON.stringify(result));
     if (result.status && result.status !== 'synchronized') process.exitCode = 1;
   } catch (error) {
-    console.log(JSON.stringify({ status: 'pending', reason: error.message, nextAction: 'Inspect the affected record and resolve this operation before claiming synchronization.' }));
+    console.log(JSON.stringify(process.argv[2] === 'inspect-hierarchy'
+      ? { status: 'inspection-unavailable', reason: error.message, nextAction: 'Read the affected configuration or record before claiming a completed inspection.' }
+      : { status: 'pending', reason: error.message, nextAction: 'Inspect the affected record and resolve this operation before claiming synchronization.' }));
     process.exitCode = 1;
   }
 }

package/skills-codex/outcome-led-planning/SKILL.md

@@ -25,7 +25,7 @@ Read the relevant current evidence, project instructions, decisions, jobs, risk
 
 Use SMART to make the objective specific, measurable through observable completion evidence, achievable against known constraints, relevant to the user's job, and time-bound using the user's stated deadline or timeframe. Qualitative evidence can establish success. Surface feasibility uncertainty instead of weakening the objective or promising certainty. Never invent numerical targets or dates. Preserve stated timing and prefer relative wording. Any added date must match verified context and its weekday. Never turn a guessed date into a new timing interview. If neither a time bound nor an explicit decision to omit one is established, ask one timing question and wait. If the user declines a time bound, record the exception honestly rather than claiming full SMART compliance.
 
-If intent is unclear or information is missing, interview the user: **ask one focused question, then stop and wait for their answer before asking the next**. Select the next question from their actual answer and remaining uncertainty. Do not bundle questions, answer on their behalf, invent their intent, or resolve ambiguity by selecting a solution. Bounded read-only investigation can establish facts within existing authority.
+If outcome information is unclear or missing, interview the user: **ask one focused question, then stop and wait for their answer before asking the next**. Select the next question from their actual answer and remaining uncertainty. Do not bundle questions, answer on their behalf, invent their intent, or resolve ambiguity by selecting a solution. Bounded read-only investigation can establish facts within existing authority.
 
 One question requests **one missing fact**. Do not combine multiple information needs, such as who benefits and what is wrong, into a multipart question. Sharing a topic or using one question mark does not make it one question.
 
@@ -113,6 +113,6 @@ Finish when the objective's completion evidence is satisfied. Record the verifie
 
 Recording verified completion is a terminal status update, not another executable plan. Any newly proposed work still needs its own assessed plan.
 
-If blocked, first exhaust useful authorized steps available to the agent. Preserve work, distinguish completed increments from unfinished outcomes, and report the precise missing evidence, capability, authority, or irreducible user action. Resume from fresh evidence when the blocker clears; do not restart completed effects.
+Before handing back a blocker, finish useful authorized work, including running checks. Preserve work, distinguish completed increments from unfinished outcomes, and report the precise missing result, capability, authority or irreducible user action. Resume from fresh evidence when the blocker clears; do not restart completed effects.
 
 Communicate the objective, consequential plan changes, decisions requiring input, exact blockers, and verified outcomes concisely. Avoid narrating routine commands or every review and wait.

package/skills-codex/outcome-led-planning/references/github-coordination.md

@@ -128,21 +128,62 @@ Give the existing planning critic the saved outcome and affected increment recor
 
 **Horizon belongs only to increments**: each planned or active increment has exactly one of Now, Next or Later. Remove completed or superseded increments from active horizons while preserving their prior position in history. **Status** separately describes execution, such as ready, in progress, blocked or done. A blocked Now increment does not automatically become Next; a completed task does not become a completed outcome. Outcomes and tasks do not inherit Horizon. Map these meanings to existing repository labels or Project fields. Replace the previous horizon when replanning rather than accumulating contradictory values.
 
-Use and verify native sub-issue relationships when supported; otherwise record explicit reciprocal parent/child links, read back both affected issue bodies and disclose the limitation. When another task supplies a required result, **create and verify its native blocked-by dependency** whenever the available API and permissions support it. Record real prerequisites even when they constrain a later stage or task completion rather than the next useful step. Name the precise start, stage or completion unlock condition and required evidence. Do not require administrative issue closure in addition to the verified result unless recorded acceptance or an applicable project rule requires it. A Ready or In progress task may retain open dependencies while useful preparation proceeds; those dependencies still gate the dependent stage or completion. Never remove a real dependency merely to make preparation available. If the native capability is unavailable or denied, record the exact limitation and reciprocal dependency links, read back both affected issue bodies. Native write denial establishes neither presence nor absence of existing links; preserve known links and report unreadable native state as unknown. Optional Project membership and fields mirror issue state; do not create a Project or fields merely because the protocol mentions them.
-
-Keep completion dependencies acyclic. A prerequisite task cannot also require its dependent's result to close. Propose corrections in the increment thread; the increment owner records revised task boundaries and acceptance with affected task owners before applying them. Obtain the five independent plan reviews before executing a materially revised plan. Give each task an independently verifiable result and retain the combined results in increment acceptance. Reassess the dependent task when a prerequisite is satisfied; independently verify its evidence before clearing that condition.
+Maintain parent/child and prerequisite relationships in this order:
+
+1. Inspect the actual relationship and the precise result that unlocks a start,
+   stage or completion. Read current native sub-issue and blocked-by state when
+   supported. A native write denial proves neither presence nor absence:
+   preserve known links and keep unreadable native state unknown.
+2. Keep completion dependencies acyclic. A prerequisite cannot require its
+   dependent's result to close. Propose changed task boundaries and acceptance
+   in the increment thread; the increment owner records agreement with affected
+   task owners before applying them. Obtain the five independent reviews before
+   materially revised execution. Give each task an independently verifiable
+   result and retain the combined results in increment acceptance.
+3. After any required agreement and reviews, use native links when supported;
+   create a missing required link or update a changed one when authorized.
+   Verify saved native state and both relationship directions. If operations are
+   unavailable, record their exact limitation plus reciprocal parent/child or
+   prerequisite/dependent text links on both affected issues; text is not proof
+   of native state. Request capable help through an authorized channel when
+   useful, without inventing a helper or widening access.
+4. Reassess actual useful work and status under the claim table below. A Ready
+   or In progress task may prepare while a real prerequisite remains open;
+   preserve its precise unlock condition and required evidence. Independently
+   verify the prerequisite result before clearing that condition and proceeding
+   with the dependent stage. Administrative issue closure is not another
+   prerequisite unless recorded acceptance or a project rule requires it.
+
+Optional Project membership and fields mirror issue state; do not create them
+merely because this protocol mentions them.
 
 Replan task boundaries at any stage when evidence changes what work is needed. Coordinate narrowed, split, replaced or dropped scope with the increment owner and affected task owners. Close redundant or superseded issues as **not planned**, with the reason and successor links; never mark undelivered work Done merely to retire it. Before removing a dependency, move still-required acceptance evidence to the appropriate task and retain it in increment acceptance. Remove only genuinely obsolete native dependencies and verify the saved result; preserve prerequisites that still constrain the revised work. Keep task briefs, links, ownership and any selected Project fields current. Routine task reconciliation within the assessed outcome and authority needs no new user approval; materially revised executable work still requires the five independent plan reviews.
 
-Reassess scope, available inputs and useful authorized next steps before deciding that a claimed task is blocked. A stored Blocked status alone does not establish exhaustion; when it is unknown, investigate or state the condition. Required watcher duties count as useful work. Apply these linked decisions to the current claim, finishing when recorded acceptance is met:
+### Status and contribution-claim decision
+
+Use this table whenever work starts, blocks, finishes or is handed over. Inspect
+scope, inputs and actual useful authorized in-task steps first: a stored Blocked
+status alone does not establish exhaustion. Genuine assigned watcher duties
+count as useful work; waiting for an unverified response or routine discussion
+reads alone do not retain an exhausted implementation reservation.
 
-| Actual state of the claimed task | Status | Claim action |
+| Actual state of the claimed task | Status | Assignment and saved result |
 | --- | --- | --- |
-| Recorded acceptance is verified with evidence | Done | Finish with evidence; preserve attribution history. |
+| Recorded acceptance is verified with evidence | Done | Post acceptance evidence, finish and preserve attribution history. |
 | Useful authorized in-task work remains | In progress | Retain the single claim and do that work. |
-| A required input is unavailable and no useful authorized in-task step remains | Blocked | Record the blocker, evidence, unlock condition and handover; remove your assignment and read back its removal. Preserve historical attribution. |
+| A required input is unavailable and no useful authorized in-task step remains | Blocked | Save the blocker, evidence, unlock condition and handover; remove your assignment and read back its removal. Preserve historical attribution. |
 
-Keep independently actionable unclaimed work Ready/Unclaimed. Preserve real prerequisites before their dependent stage; never invent busywork to avoid Blocked. Reassess when evidence changes. A blocked task does not block every contribution. If assignment mutation or verification is unavailable, record the exact pending release and current known claim state, use an authorized owner/channel when available, and do not claim an unverified release or take another task while still assigned.
+One contribution claim is a ceiling, not a retention requirement. A blocked
+assignment still counts until release is verified. Apply the table before
+claiming another task; never reserve queued tasks. Outcome/increment ownership
+does not reserve contributions. Agents sharing an account remain distinct by
+their recorded agent/session. Keep actionable unclaimed work Ready/Unclaimed;
+a blocked task does not block every contribution. Never invent busywork.
+
+If assignment mutation or verification is unavailable, record the exact pending
+release and known claim state, use an authorized owner/channel when available,
+and do not claim release or take another task while still assigned. Reassess
+when evidence changes.
 
 ## Join, claim and contribute
 
@@ -151,71 +192,81 @@ Use this contribution lifecycle:
 1. Read the outcome, current Now revision, discussion, dependencies and claims. Reconcile stale scope before dependent work.
 2. Choose a bounded useful result and announce its acceptance and file/operation boundary in the increment thread. Resolve overlap, shared operations or authority questions with affected owners. A non-overlapping task within the assessed Now needs no allocator approval.
 3. Reuse a matching unclaimed task, or create your own just before work. Apply the established task-kind marker (`kind:task` by default). Assign it to the **actual authenticated account** and record the **specific agent/session** and native links; read back kind, assignment, claim and links and recheck competing work. For a selected or required Project, explicitly add the task and read back its membership and applicable fields so it matches the saved view.
-4. Execute within the assessed plan and authority, keeping status and evidence current. Finish with verified evidence or release with a handover stating evidence, blocker and next step.
+4. Execute within the assessed plan and authority; apply the status and contribution-claim decision above, including saved release when exhausted.
 5. Choose and document the next useful contribution from the remaining outcome gap, then repeat these checks before claiming it.
 
 A starting battle plan exposes likely work, dependencies and parallel opportunities without precreating, assigning or reserving every future task. The increment owner keeps acceptance, sequence and integration clear and resolves overlap/dependencies. Explicit assignments and handoffs remain valid. Two agents sharing an account are distinct contributors. Checklists suffice for routine steps; do not create a task for every command. Task creation within assessed scope requires no fresh human approval.
 
-**Each agent holds only one contribution task at a time**, including a blocked assignment. Finish, explicitly hand over or release the current assignment before claiming another. Do not reserve queued tasks. Outcome or increment coordination ownership does not reserve contribution tasks. Agents sharing an account remain distinct through their recorded agent/session identities.
-
 Before declaring a contribution ready to start, complete this claim receipt: **no other contribution assignment held; parent increment; current assessed plan revision; non-overlapping scope; dependencies (or explicitly none); actual account; distinct agent/session; saved claim and reciprocal-link readback; competing-claim recheck.** Record all fields on the task, even when some are already known in conversation. Assignment does not increase authority. When explaining a proposed claim, make these required fields and the before/after overlap checks explicit.
 
 Record scope boundaries and dependencies, then read back the claim, links and any competing claims. Issue claims are cooperative, not atomic locks: another agent may have claimed overlapping work since your first read. Reconcile that race before dependent implementation. If another contributor has claimed the same work, agree a split or handoff in the increment thread before overlapping implementation. An inactive or old claim is not permission to take over silently. If assignment is unavailable, record the intended owner and unassigned state, request the owner’s help through the agreed coordination channel when authorized, and continue only work whose ownership is clear. Never claim an assignment or board update succeeded without reading it back.
 
 ## Reconcile tracking at work checkpoints
 
-Use **two complementary discussion checks**:
-
-1. **Throughout active work:** read new increment comments regularly between
-   bounded work cycles while coding or waiting, following the agreed, recorded
-   cadence. Until agreement exists, continue already-authorized regular bounded
-   reads; proposing a cadence does not replace those reads.
-2. **At events:** check on joining or resuming and again at the checkpoints below,
-   including before dependent actions, pushes, scope/ownership changes and handovers.
-   Neither duty replaces the other: regular-only and checkpoint-only reads
-   are both incomplete.
-
-Propose an appropriate bounded cadence through the authorized increment thread,
-obtain agreement and verify its saved record before calling it agreed. A suggested
-interval alone is not an agreement. Record pending agreement honestly without
-suspending either kind of check. These are checks during an active work window,
-not a standing poller or a promise to wake an idle agent.
-
-Read relevant new comments, acknowledge handoffs and answer questions affecting
-your work through already-authorized channels. Keep task records current with
-the resulting evidence or changes. A posted message is not the recipient's
-actual acknowledgement.
+During an active work window, follow this coordination sequence while coding
+or waiting:
+
+1. Use the agreed, saved discussion-reading cadence. If none exists, propose a
+   bounded cadence through the authorized increment thread, obtain agreement
+   and verify its saved record. While agreement is pending, continue regular
+   bounded reads; a proposal is not agreement.
+2. Also read new increment comments on joining/resuming and at the event
+   checkpoints below, including before dependent actions, pushes, scope or
+   ownership changes and handovers. Regular reads and event reads are both
+   required; neither replaces the other.
+3. Answer relevant questions and handle handoffs through the authorized channel
+   and handoff rules below: actual recipient
+   acknowledgement and linked task, independent verification of returned
+   evidence, and updates to your task's evidence, dependency and next action.
+   A posted message is not the recipient's acknowledgement.
+4. If the result materially changes the executable plan, reconcile that revision
+   and obtain the five independent reviews before dependent execution. Otherwise
+   continue within the assessed plan. Apply the claim table when work is
+   exhausted rather than retaining it for discussion reads.
+
+These are bounded checks during active work, not a standing poller or a promise
+to wake an idle agent. Use only already-authorized communication channels.
 
 At each work checkpoint, reconcile tracking in this order:
 
-For a join/resume checkpoint with a selected Project and working `gh`, MUST use
-the [executable Project checkpoint](github-project-checkpoint.md). Read its
-inspection and handle current discussion before applying it; do not manually
-publish synchronization-success text on that route. Other checkpoints and
-authorized alternatives retain the rules below.
-
-1. **Establish scope.** Reuse the established backend. Establish Project selection
-   separately from the backend, using configuration, project requirements or
-   explicit direction: selected/required, none, or unresolved. Do not infer none
-   or an unset configuration from omitted information. An established choice to
-   use no Project needs no setup. While selection remains unresolved, inspect available
-   records and keep Project work conditional; do not assert a pending or
-   unsynchronized mirror. An unavailable API or bootstrap default proves neither
-   selection nor a missing view, field or membership; inspect saved setup before
-   naming gaps.
-2. **Inspect each affected record.** Read each outcome, increment and task
-   against the minimum-information table above. Preserve its own owner/account,
-   applicable agent/session, revision and acceptance; mark missing required
-   information unresolved. Record current scope, actual status, increment-only
-   Horizon, dependencies or blocker, next action and state-appropriate evidence.
-   Preserve completed tasks' recorded revisions and acceptance criteria;
-   completion evidence does not replace either. A provisional increment retains
-   its recorded owner, brief revision and tentative acceptance, marking missing
-   values unresolved. These do not imply an executable plan, critic approval or
-   completion evidence.
-   For a selected or required Project, Status reflects actual work and Agent
-   belongs to that item's verified owner/session: never copy the task contributor
-   upward or replace another owner's identity.
+When the affected records include an outcome, current Now, provisional Next and
+a task, and `gh` works, MUST first use the [read-only hierarchy inspector](github-project-checkpoint.md#inspect-the-hierarchy).
+Construct its request from those actual records and consume its findings before
+claiming completeness; identical draft/remote text is not that comparison.
+Do not manufacture a Next issue for this route. Its configuration report is one
+source for the selection decision below, not proof of capability or acceptance.
+
+1. **Establish selection before checking Project capability.** Reuse the
+   established backend. From configuration, project requirements or explicit
+   direction, choose the applicable branch:
+   - **Selected/required:** verify the repository, Project and account, then
+     inspect its saved setup and applicable operations. For join/resume of an
+     active open task with working `gh`, MUST use the [executable Project checkpoint](github-project-checkpoint.md).
+     Read its inspection and handle current discussion before applying it;
+     do not manually publish synchronization-success text on that route.
+     If an applicable operation is unavailable, retain its exact pending state
+     under the recovery rules below. An unavailable API or bootstrap default
+     does not prove a missing view, field or membership.
+   - **Established none:** continue issue-side reconciliation without Project
+     setup, fields or synchronization.
+   - **Unresolved:** inspect available configuration, requirements, direction and
+     issue records. Record the selection gap and keep Project work conditional;
+     there is no established mirror operation to report pending or unsynchronized.
+     Omitted information and API availability establish neither selection nor
+     an explicit choice to use no Project.
+2. **Inspect each affected record before classifying it.** Compare every
+   outcome, increment and task with the minimum-information table. Preserve its
+   own recorded owner/account, applicable agent/session, revision and acceptance,
+   including provisional and completed records. Mark a required value unresolved
+   only when inspection cannot establish it; omission from a scenario or summary
+   does not establish that saved information is missing. Completion evidence
+   does not replace the task's own revision or acceptance. Provisional ownership,
+   revision and tentative acceptance imply neither an executable plan nor
+   critic approval or completion evidence.
+   Record actual scope, status, increment-only Horizon, dependencies/blocker,
+   next action and state-appropriate evidence. For a selected/required Project,
+   each item's Agent remains its verified owner/session, never an identity
+   copied from its parent or child; Status reflects that item's actual work.
 3. **Update and verify.** Make only necessary authorized changes to existing
    records. Read back every changed issue's fields and links, checking both
    directions of parent/dependency relationships. For a selected or required
@@ -235,7 +286,7 @@ system.
 | Join, resume or start implementation | Read current records and discussion; correct stale status, scope and ownership before dependent implementation. Set the active task and increment In progress when useful work starts. Complete missing selected Project setup or record its precise unavailable operation. |
 | Material milestone or failed verification | Record the actual result and evidence before the next dependent action. Keep In progress while useful repair remains; a failed check alone does not mean Blocked. |
 | Scope, dependency, plan or horizon change | Update affected briefs, native relationships and increment horizons; remove superseded active horizons. Obtain the required reviews before materially revised execution. |
-| Block, hand off, finish or yield the active work window | Record the exact remaining gap, next action and owner, or acceptance evidence for completion. Reconcile the increment as well as the task; do not leave an old Todo/Ready or stale next action for someone else to discover. |
+| Block, hand off, finish or yield the active work window | Apply the claim table, saving the gap, next action/owner or acceptance evidence and verifying any required release. Reconcile the increment as well as the task; do not leave stale status or next action. |
 
 For a selected or required Project, when an operation is unavailable, record
 the affected view/field/item,
@@ -271,7 +322,7 @@ When an authorized owner must complete a pending Project operation, request it t
 
 ## Verify, learn and replan as the outcome owner
 
-Post acceptance evidence before completing a task. Preserve its actual recorded acceptance: do not invent a later release check as a repair-task completion condition, or remove an established condition to finish early. At handoff, state one coherent claim transition: retain it while useful authorized work remains within its scope, finish when acceptance is met, release it unassigned with the remaining gap, or transfer to an identified owner after acknowledgement. Do not report both releasing and retaining the same claim. The increment owner verifies the whole increment against its criteria before closing it; task completion alone does not establish delivery. Publication, installed behavior and production/customer verification remain separate evidence stages where applicable.
+Post acceptance evidence before completing a task. Preserve its actual recorded acceptance: do not invent a later release check as a repair-task completion condition, or remove an established condition to finish early. At handoff, apply the claim table; an explicit ownership transfer additionally needs the identified recipient's acknowledgement. Do not report both releasing and retaining the same claim. The increment owner verifies the whole increment against its criteria before closing it; task completion alone does not establish delivery. Publication, installed behavior and production/customer verification remain separate evidence stages where applicable.
 
 After a verified increment, or earlier when evidence invalidates the plan, the outcome owner:
 

package/skills-codex/outcome-led-planning/references/github-project-checkpoint.md

@@ -1,6 +1,72 @@
-# Execute a selected-Project resume checkpoint
+# Inspect and reconcile GitHub records
 
-For a join/resume checkpoint with a selected GitHub Project and working `gh`,
+Resolve `scripts/github-project-checkpoint.mjs` relative to this installed
+planning skill, including when called from `contribute`. Use the existing
+authenticated `gh` account and saved project configuration. The default is
+`.agents/planning.json`; an existing project-declared configuration path may be
+supplied last. These operations require no new grants, account changes or tokens.
+Local tracking keeps its existing path.
+
+## Inspect the hierarchy
+
+When reconciling an outcome, current Now, an affected provisional Next and a
+task together with working `gh`, planning and `contribute` MUST first use the
+read-only hierarchy inspector. Supply those actual distinct issue numbers;
+do not invent a Next issue to satisfy the command. Other record sets retain
+their existing coordination path.
+
+```json
+{
+  "outcome": 1,
+  "increment": {"issue": 2},
+  "next": {"issue": 3},
+  "task": {"issue": 4}
+}
+```
+
+Run `node <installed-planning-skill>/scripts/github-project-checkpoint.mjs inspect-hierarchy request.json`.
+This reads the four actual issues and their returned comments. It writes
+nothing and makes no Project or native-link request. Read the raw records and
+consume `findings` before claiming that the records are correct:
+
+- `projectSelection` reports configuration facts. `not-recorded` means selection
+  is unresolved from that configuration, not an explicit choice to use no
+  Project. `recorded` does not prove capability; consider actual project
+  requirements and explicit direction too. Preserve invalid configuration.
+- Each record's `inspection` reports literal owner, revision, acceptance and
+  Parent candidates with raw line evidence. `candidate` is text, not verified
+  ownership or passed acceptance. `explicitly-unresolved` preserves a recorded
+  unknown. Empty/missing literals, unsupported syntax and multiple candidates
+  remain unestablished by this inspector; they do not prove semantic information
+  is absent or that the issue is invalid. Inspect the actual prose/history
+  rather than forcing a new format or choosing a historical value.
+- `textLinks` compares the three requested textual relationships. A mention is
+  observed text, not proof of a current native relationship. Inspect both sides
+  and repair known reciprocal gaps under the existing coordination rules.
+- `capabilities` are `not-probed`; do not turn that into an outage or native-link
+  absence. `inspection-unavailable` means the read/report operation failed,
+  not that a Project mirror is pending.
+
+A successful command produces a diagnostic report, never a correctness or
+synchronization verdict. Identical drafts and saved bodies do not establish
+completeness. Before claiming completeness, account for every finding through
+actual semantic review, authorized repair with saved readback where needed, or
+honest unresolved recording in the existing plan or record. Follow the selection
+finding's conditional next action, which targets the existing outcome issue
+for saving and reading back a still-unresolved gap. Reuse an already saved gap
+without an unchanged write. Configuration alone may leave the choice unresolved
+while requirements or explicit direction establish it. Unsupported
+syntax does not force normalization or another artifact.
+Apply the existing per-record rules to known gaps, marking missing
+required information unresolved rather than inventing it; preserve completed
+acceptance and attribution. Read back authorized changes and compare reciprocal
+links before reporting reconciliation. Unsupported syntax needs actual review,
+not automatic normalization. Semantic acceptance remains with the caller and
+required independent review.
+
+## Synchronize selected Project fields
+
+For a join/resume checkpoint on an active open task with a selected GitHub Project and working `gh`,
 planning and `contribute` MUST use the bundled
 `scripts/github-project-checkpoint.mjs` operation. Do not manually publish a
 Project synchronization-success claim on this route. The operation reads the
@@ -8,10 +74,8 @@ records/discussion, updates the two items, verifies their saved fields and only
 then generates the task's synchronization result. It does not allocate owners,
 approve a plan, acknowledge another person or complete the increment.
 
-Resolve the script relative to this installed planning skill, including when
-called from `contribute`. Use the existing authenticated `gh` account and saved
-project configuration; no new grants, account changes or tokens are required by
-the operation. Local and GitHub Issues-only tracking keep their existing paths.
+This mutation route applies to its open outcome, increment and active task.
+GitHub Issues-only tracking uses no Project field mutations.
 
 ## Inspect, decide, apply
 

package/skills-codex/outcome-led-planning/scripts/github-project-checkpoint.mjs

@@ -26,10 +26,14 @@ function json(args, input) {
   if (value.errors?.length) throw new Error(value.errors.map(error => error.message).join('; '));
   return value;
 }
-function scope(request, config) {
-  requireValue(config.version === 1 && config.backend === 'github', 'This operation requires the saved GitHub backend.');
+function repositoryFor(config) {
+  requireValue(config?.version === 1 && config.backend === 'github', 'This operation requires the saved GitHub backend.');
   const repository = config.github?.repository;
-  requireValue(typeof repository === 'string' && /^[\w.-]+\/[\w.-]+$/.test(repository), 'Invalid configured GitHub repository.');
+  requireValue(typeof repository === 'string' && /^[A-Za-z0-9](?:[A-Za-z0-9-]*[A-Za-z0-9])?\/[\w.-]+$/.test(repository) && !['.', '..'].includes(repository.split('/')[1]), 'Invalid configured GitHub repository.');
+  return repository;
+}
+function scope(request, config) {
+  const repository = repositoryFor(config);
   const url = new URL(config.github?.projectUrl);
   const match = url.pathname.match(/^\/(?:users|orgs)\/([\w.-]+)\/projects\/([1-9]\d*)(?:\/views\/[1-9]\d*)?\/?$/);
   requireValue(url.protocol === 'https:' && url.hostname === 'github.com' && match && !url.username && !url.password, 'A selected GitHub Project URL is required.');
@@ -44,6 +48,66 @@ function scope(request, config) {
 function issue(number, bound) {
   return json(['issue', 'view', String(number), '--repo', bound.repository, '--json', 'number,url,body,state,assignees,labels,comments']);
 }
+function briefField(body, pattern, cue) {
+  // shortcut: observed literal brief fields only; extend when an actual brief needs another syntax.
+  const lines = body.split(/\r?\n/).map((text, index) => ({ line: index + 1, text }));
+  const matches = lines.flatMap(line => {
+    const match = line.text.match(pattern);
+    return match ? [{ ...line, value: match[1].trim() }] : [];
+  });
+  const literalEvidence = matches.map(({ line, text }) => ({ line, text }));
+  if (matches.length > 1) return { state: 'multiple-candidates', evidence: literalEvidence };
+  if (matches.length === 1) {
+    const { value } = matches[0];
+    return { state: !value ? 'empty' : /^(?:unresolved|unknown|tbd|unclaimed)(?:\b|$)/i.test(value) ? 'explicitly-unresolved' : 'candidate', value, evidence: literalEvidence };
+  }
+  const evidence = lines.filter(line => cue.test(line.text));
+  return { state: evidence.length ? 'unsupported-format' : 'literal-field-missing', evidence };
+}
+function textReference(body, number, repository) {
+  const escaped = repository.replace(/[.*+?^${}()|[\]\\]/g, '\\$&');
+  const reference = new RegExp(`(?:(?<![\\w./#:-])#${number}\\b|https://github\\.com/${escaped}/issues/${number}(?![\\w/]))`, 'i');
+  const evidence = body.split(/\r?\n/).flatMap((text, index) => reference.test(text) ? [{ line: index + 1, text }] : []);
+  return { observed: evidence.length > 0, evidence };
+}
+function inspectHierarchy(request, config) {
+  const repository = repositoryFor(config);
+  const roles = { outcome: request?.outcome, increment: request?.increment?.issue, next: request?.next?.issue, task: request?.task?.issue };
+  requireValue(Object.values(roles).every(n => Number.isSafeInteger(n) && n > 0) && new Set(Object.values(roles)).size === 4, 'Four distinct outcome, increment, next and task issue numbers are required.');
+  const projectSelection = { state: 'not-recorded', source: 'configuration' };
+  if (Object.hasOwn(config.github, 'projectUrl')) {
+    try {
+      const url = new URL(config.github.projectUrl);
+      requireValue(url.protocol === 'https:' && url.hostname === 'github.com' && !url.username && !url.password && !url.search && !url.hash && /^\/(?:users|orgs)\/[\w.-]+\/projects\/[1-9]\d*(?:\/views\/[1-9]\d*)?\/?$/.test(url.pathname), 'Invalid recorded Project URL.');
+      Object.assign(projectSelection, { state: 'recorded', url: `https://github.com${url.pathname.split('/views/')[0].replace(/\/$/, '')}` });
+    } catch { projectSelection.state = 'invalid'; }
+  }
+  const records = {};
+  const findings = projectSelection.state === 'recorded' ? [] : [{ issue: roles.outcome, field: 'projectSelection', state: projectSelection.state, nextAction: `Establish selection from applicable project requirements and explicit direction. If it remains unresolved, save that selection gap and conditional Project work on outcome #${roles.outcome} and read back its saved body before claiming reconciliation complete. Reuse an already saved gap without an unchanged write.` }];
+  for (const [role, number] of Object.entries(roles)) {
+    const record = issue(number, { repository });
+    requireValue(record.number === number && record.url?.toLowerCase() === `https://github.com/${repository}/issues/${number}`.toLowerCase() && typeof record.body === 'string', 'Returned issue does not match its requested repository/number or brief.');
+    const inspection = {
+      owner: briefField(record.body, /^\s*(?:(?:Outcome|Increment|Task) )?Owner:\s*(.*)$/i, /\bowner\b/i),
+      revision: briefField(record.body, /^\s*Revision:\s*(.*)$/i, /\brevision\b/i),
+      acceptance: briefField(record.body, /^\s*(?:Tentative )?Acceptance(?: criteria| evidence)?:\s*(.*)$/i, /\bacceptance\b/i),
+      parent: briefField(record.body, /^\s*Parent(?: outcome| increment)?:\s*(.*)$/i, /\bparent\b/i)
+    };
+    records[role] = { ...record, inspection };
+    for (const field of ['owner', 'revision', 'acceptance']) {
+      if (!['candidate', 'explicitly-unresolved'].includes(inspection[field].state)) findings.push({ issue: number, field, state: inspection[field].state });
+    }
+  }
+  const textLinks = [[records.outcome, records.increment], [records.outcome, records.next], [records.increment, records.task]].map(([parent, child]) => {
+    const parentMentionsChild = textReference(parent.body, child.number, repository);
+    const field = child.inspection.parent;
+    const referencesExpected = 'value' in field ? textReference(field.value, parent.number, repository).observed : null;
+    if (!parentMentionsChild.observed) findings.push({ issue: parent.number, field: 'child-text-reference', state: 'not-established', child: child.number });
+    if (referencesExpected !== true) findings.push({ issue: child.number, field: 'parent-text-reference', state: 'not-established', parent: parent.number });
+    return { parent: parent.number, child: child.number, parentMentionsChild, childParent: { ...field, referencesExpected } };
+  });
+  return { repository, projectSelection, capabilities: { project: 'not-probed', nativeLinks: 'not-probed' }, records, textLinks, findings };
+}
 function items(request, bound, projectId) {
   const response = json(['api', 'graphql', '--input', '-'], JSON.stringify({ query: itemQuery, variables: { ids: [request.increment.itemId, request.task.itemId], agentFieldId: request.agentFieldId } }));
   requireValue(response.data.agentField?.dataType === 'TEXT', 'The Agent field must be a text field.');
@@ -125,18 +189,20 @@ function apply(request, inspection, config) {
 }
 
 if (process.argv[2] === '--help') {
-  console.log('Inspect: node github-project-checkpoint.mjs inspect REQUEST.json [CONFIG.json]\nApply: node github-project-checkpoint.mjs apply REQUEST.json INSPECTION.json [CONFIG.json]');
+  console.log('Hierarchy: node github-project-checkpoint.mjs inspect-hierarchy REQUEST.json [CONFIG.json]\nInspect: node github-project-checkpoint.mjs inspect REQUEST.json [CONFIG.json]\nApply: node github-project-checkpoint.mjs apply REQUEST.json INSPECTION.json [CONFIG.json]');
 } else {
   try {
     const [mode, requestPath, third, fourth] = process.argv.slice(2);
-    requireValue(mode === 'inspect' || mode === 'apply', 'Expected inspect or apply; use --help for usage.');
+    requireValue(['inspect', 'apply', 'inspect-hierarchy'].includes(mode), 'Expected inspect-hierarchy, inspect or apply; use --help for usage.');
     const request = load(requestPath);
-    const config = load((mode === 'inspect' ? third : fourth) || '.agents/planning.json');
-    const result = mode === 'inspect' ? inspect(request, config) : apply(request, load(third), config);
+    const config = load((mode === 'apply' ? fourth : third) || '.agents/planning.json');
+    const result = mode === 'inspect-hierarchy' ? inspectHierarchy(request, config) : mode === 'inspect' ? inspect(request, config) : apply(request, load(third), config);
     console.log(JSON.stringify(result));
     if (result.status && result.status !== 'synchronized') process.exitCode = 1;
   } catch (error) {
-    console.log(JSON.stringify({ status: 'pending', reason: error.message, nextAction: 'Inspect the affected record and resolve this operation before claiming synchronization.' }));
+    console.log(JSON.stringify(process.argv[2] === 'inspect-hierarchy'
+      ? { status: 'inspection-unavailable', reason: error.message, nextAction: 'Read the affected configuration or record before claiming a completed inspection.' }
+      : { status: 'pending', reason: error.message, nextAction: 'Inspect the affected record and resolve this operation before claiming synchronization.' }));
     process.exitCode = 1;
   }
 }