@c4a/context-cli 0.6.1 → 0.6.3

package/plugins/codex/skills/continue/references/internal-procedures/skill-prose-compile/references/internal-procedures/semantic-judgment/references/leakage-and-ownership.md

@@ -1,55 +0,0 @@
-# Context-only Leakage and Ownership Repair
-
-Consult this reference when current compile validation or review diagnostics say
-a source ref is not owned by the selected planned section, is context-only, or
-belongs to another node/section.
-
-## What The Diagnostic Means
-
-Compile is source-bound to the confirmed structure. A section action may cite
-only source refs owned by the planned section it targets. Background/context
-evidence may explain the node, but it cannot become the support basis for an
-active section until align confirms that ownership.
-
-This is a hard boundary. Do not paraphrase context-only evidence, do not switch
-to a looser summary, and do not add an unsourced claim to avoid the diagnostic.
-
-## Repair Routes
-
-Use the same three-way repair discipline as the current semantic review gate,
-and express it through the current compile/align surfaces:
-
-| Situation | Route |
-|---|---|
-| Another owned planned-section ref supports the same claim | Repair the compile action to cite that owned ref from the same node-context and revalidate. Do not keep the leaking ref as secondary evidence. |
-| No owned evidence exists and the claim is not load-bearing for this node | Ask the user whether to leave it unwritten; if confirmed, emit a current `skip` with a business reason when the schema supports reviewed skips, or leave an align handoff note. |
-| The context-only / secondary evidence contains facts this node legitimately needs | Stop compile and return to prose align. Revise `context.structure.v1` so the source refs are owned by the correct planned section, or keep an `unresolved[]` ownership issue. |
-| The evidence belongs under another node | Return to prose align and move the planned section/source refs to that node, or add an unresolved structure issue. |
-| The ownership problem indicates a missing relation | Return to prose align and add a source-backed typed edge or unresolved relation. |
-
-Do not collapse the second and third rows into a generic skip. If the evidence
-is load-bearing, skipping hides a structure defect; the correct long-term
-repair is to reconfirm structure.
-
-## What Not To Do
-
-- Do not use full-text/detail views as an ownership upgrade. They expose text;
-  they do not change the confirmed structure.
-- Do not cite a secondary or context-only ref for active body text.
-- Do not paraphrase the offending evidence while still citing it. The support
-  boundary remains wrong even if the prose changes.
-- Do not silently skip to clear the diagnostic; this may hide a real evidence
-  gap or missing ownership decision.
-- Do not switch the action to a different node, target section, or edge merely
-  to dodge the ownership rule. Return to align and reconfirm the structure.
-- Do not add a cross-node link inside verbatim content.
-- Do not write content that depends on evidence outside the planned section.
-  Return to align first.
-
-## Self-verify
-
-- [ ] Every active compile action cites only refs owned by its planned section.
-- [ ] Ownership repairs were revalidated.
-- [ ] Structure-level repairs returned to prose align.
-- [ ] User-confirmed no-write was used only for non-load-bearing evidence.
-- [ ] Context-only evidence was not converted into reader-facing fact text.

package/plugins/codex/skills/continue/references/internal-procedures/skill-prose-compile/references/internal-procedures/semantic-judgment/references/scope-review-and-omit.md

@@ -1,93 +0,0 @@
-# Scope Review and No-write Discipline
-
-Consult this reference when you are tempted not to write citation-eligible
-evidence, or when a proposed action looks redundant, low-value, miscoped, or
-outside the current node.
-
-## Core Rule
-
-No-write is never a shortcut for uncertainty. It is valid only when one of these
-conditions is true:
-
-- the evidence is pure navigation, placeholder, duplicate, or unchanged content;
-- the source refs are not owned by the selected planned section and must return
-  to structure confirmation;
-- the user explicitly confirms that this citation-eligible material should not
-  become active knowledge;
-- the current CLI diagnostics instruct a skip/no-write route.
-
-Unsupported evidence is not a no-write shortcut. First repair the source refs,
-narrow the claim, or return to prose align. Schema/source-ref failures must be
-fixed, not hidden by skipping.
-
-## Scope Review Pass
-
-Before choosing a no-write outcome for citation-eligible evidence, inspect the
-current node context and proposed actions:
-
-1. **Covered-by check** — is the same source-backed claim already covered by
-   another current action, approved section, or confirmed planned section?
-   - Yes -> skip this action with a precise duplicate/covered-by reason when
-     the current schema supports skip. Do not call this "omit"; it is a
-     duplicate decision.
-
-2. **Mergeable check** — should this evidence strengthen another write action?
-   - Yes -> repair that other action only if the current schema exposes a safe
-     update/merge path and the merged evidence boundary still supports every
-     sentence. Do not drop the standalone evidence until the repaired action
-     validates.
-
-3. **Wrong node or section check** — does the evidence belong elsewhere?
-   - Yes -> return to prose align and revise section ownership, node assignment,
-     or typed edges. Do not paper over a wrong structure with skip decisions.
-
-4. **Low-value but citation-eligible / provable low-value check** — can the current evidence prove that this item
-   is navigation, placeholder, empty, non-knowledge, or outside the package's
-   intended scope?
-   - Yes -> ask the user whether to leave it unwritten, presenting the business
-     claim and evidence in normal language.
-   - No -> ask the user with the same evidence instead of silently omitting it;
-     the agent's hunch is not a scope decision.
-
-5. **Scope-wide miscope check** — do several items look low-value, or does the
-   node boundary / planned section split look wrong?
-   - Yes -> stop compile for this node and return to structure confirmation.
-     A series of skips is not a substitute for correcting the structure.
-
-## User Confirmation
-
-When user confirmation is needed, ask a concrete question such as:
-
-```text
-This evidence appears source-backed but low-value for the active knowledge page:
-<business claim>
-
-Should it be left out of this compile round, or should it become a section?
-```
-
-Only after a specific user answer may the current action be skipped for business
-scope reasons. General "continue" permission, delegated execution, or permission
-to run commands is not confirmation.
-
-## How This Slots Into The Main Procedure
-
-- In compile drafting, use `skip` only when the current schema supports it and
-  the reason is explicit.
-- In structure repair, put unresolved scope problems in `unresolved[]` or return
-  to the prose align gate.
-- In review, do not approve a no-write outcome merely because it clears the
-  queue; the user must have seen the relevant evidence and decision.
-- No-write decisions are current-phase records only. They are not a substitute
-  for approved knowledge, and they should not be treated as durable evidence
-  that the source was fully handled unless the current ledger/diagnostic surface
-  explicitly records that reviewed skip.
-
-## Self-verify
-
-- [ ] No citation-eligible claim was omitted without duplicate, scope, CLI, or
-  user-confirmed reason.
-- [ ] Covered-by and mergeable checks ran before asking the user to omit.
-- [ ] Scope-wide miscope returned to prose align instead of many local skips.
-- [ ] Unsupported evidence was repaired or returned upstream, not hidden.
-- [ ] Structure problems returned to prose align.
-- [ ] User-facing questions did not expose internal ids as the choice.

package/plugins/codex/skills/continue/references/internal-procedures/skill-prose-compile/references/internal-procedures/semantic-judgment/references/temporal-and-evidence.md

@@ -1,79 +0,0 @@
-# Temporal Priors and Evidence Boundary Pointers
-
-Consult this reference when current compile or review diagnostics mention:
-
-- source capture time, stale evidence, or temporal-prior context;
-- source-ref boundary problems;
-- long `summary` text that may be lost during repair;
-- command, config, URL, table, or code-fence evidence.
-
-## Temporal Priors
-
-Temporal information explains context; it does not authorize a write by itself.
-
-- It can explain why previous approved content may need review.
-- It cannot prove a replacement, conflict resolution, or deletion without
-  source-backed evidence.
-- It must not change the default semantic route by itself. A newer capture time
-  can justify asking a stale-source question; it cannot by itself prove that the
-  newer wording supersedes older approved knowledge.
-- It is never enough on its own to auto-merge, auto-replace, auto-deprecate, or
-  auto-skip a claim.
-- It should appear in user-facing rationale only when it helps the user decide a
-  concrete conflict or stale-source question.
-
-Do not copy temporal metadata into compile actions unless the current schema
-explicitly accepts that field.
-
-## Evidence Boundary Repair
-
-When a diagnostic says a source ref is invalid, stale, too narrow, too broad, or
-owned by the wrong section, repair with current CLI views only:
-
-- use canonical `source_refs[]` from `node-context`, `source-index`,
-  `span-detail`, or `span-text`;
-- treat nearby refs, line ranges, chunk ids, or headings returned by diagnostics
-  as repair hints, not automatic broadening permission;
-- broaden a range only when the entire broader range supports the final claim;
-- split the claim when different sentences require unrelated refs;
-- return to prose align when the needed evidence belongs to another planned
-  section, node, or relation.
-
-Do not invent line ranges, copy stale refs from unrelated payloads, or cite navigation
-text as support for a substantive claim.
-
-After broadening, narrowing, or splitting evidence boundaries, re-run the
-current validate/review route before staging or applying. A source ref that is
-plausible to the agent is not accepted until the CLI revalidates it against the
-committed snapshot.
-
-## Summary Preservation And Reader Body Boundary
-
-Current compile actions do not author reader-facing body text. The CLI
-materializes approved bodies by mirroring validated source refs. Treat summary
-as the only LLM-authored prose field in compile actions:
-
-- `summary` is recall/query aid; it must stay faithful to the action.
-- If the cited source can be mirrored directly, prefer omitting `content` and
-  letting the CLI materialize verbatim.
-- Preserve source-backed URLs, tables, command/config/code fences, identifiers,
-  numbers, and named entities by mirroring the source span or splitting the
-  section. Do not compress them into compile-written content.
-- Do not add `content` or `content_intent` to repair a boundary problem. The
-  current parser rejects those fields. If a source range cannot be mirrored,
-  split the section, choose a different source ref, or return to align.
-- Do not use summary as a substitute for source-backed reader body.
-- Clearing a summary is an explicit choice. If the current schema exposes a
-  summary field and the previous action had one, carry it forward unless the
-  repair deliberately removes it.
-
-## Self-verify
-
-- [ ] Temporal context was not used as sole evidence.
-- [ ] Every repaired ref came from a current CLI evidence view.
-- [ ] Summary was preserved unless a current rule justified changing it.
-- [ ] No `content`, `content_intent`, or rewrite-route field was added to a
-  compile action.
-- [ ] Any broadened or split evidence boundary was revalidated before staging or
-  review apply.
-- [ ] No temporal metadata leaked into a schema that does not accept it.

package/plugins/codex/skills/continue/references/internal-procedures/skill-prose-compile/references/internal-procedures/semantic-judgment/references/user-confirmation.md

@@ -1,111 +0,0 @@
-# User Confirmation Paths
-
-Consult this reference when weak evidence, conflict resolution, or no-write
-scope requires a human choice before compile/review can
-continue.
-
-## What Counts As Confirmation
-
-Only a specific user reply to a specific current question counts. These are not
-confirmation:
-
-- delegated mode;
-- a blanket "continue" or "yes go ahead" from earlier in the session;
-- permission to run shell commands;
-- an approval for a different node, section, source, or earlier compile round.
-
-If you cannot point at the exact current question and answer, ask the user
-again or leave the issue unresolved.
-
-## When To Ask
-
-Ask the user when:
-
-- evidence is weak and may require a business decision before it can be
-  represented as source-mirrored knowledge;
-- two source-backed claims conflict;
-- citation-eligible material looks low-value and may be intentionally left out;
-- structure ownership or relation intent is ambiguous and cannot be decided from
-  evidence alone.
-
-The question should use business language. Do not expose internal source-ref ids,
-section ids, or payload paths as the choices.
-
-## Weak Support Handling
-
-Weak support means the cited source refs plausibly support a business decision,
-but the agent cannot mirror the reader-facing wording from one continuous source
-span without changing meaning.
-
-Rules:
-
-- Weak support is not a compile-time license to write summarized or rewritten
-  body text.
-- It is not acceptable for an update, replacement, withdrawal, ownership move,
-  relation reversal, or section relocation unless stronger source evidence or a
-  fresh structure confirmation backs that change.
-- Present the business claim and the cited evidence meaning to the user. Do not
-  ask "confirm source_ref X" or expose section ids as the choice.
-- If the user confirms, express that confirmation through the current surface:
-  lifecycle confirmation for structure, or a source-backed skip/unresolved
-  reason. If the user declines, narrow the claim, cite stronger evidence, split
-  the section, or leave the item unresolved.
-
-User confirmation permits weak support; it does not permit unsupported evidence,
-contradictory claims, fabricated relationships, or stale source refs.
-
-## No-write / Scope Confirmation
-
-Use this when citation-eligible material looks real but may be intentionally
-left unwritten because it is duplicate, navigation-only, out of scope, too weak,
-or better owned by another node.
-
-- If the user confirms no-write, record it as a current `skip` with
-  `source_refs[]` when the compile schema permits reviewed skips, or as a
-  structure `unresolved[]` / handoff note when the decision belongs to align.
-- If the user declines no-write, revise the structure or compile action into a
-  concrete source-backed write.
-- Do not silently omit citation-eligible evidence merely because it feels low
-  value. Either cite a reviewed skip, leave an unresolved item, or ask the user.
-
-## How To Record The Answer
-
-Use the current phase surface, not a separate decision schema:
-
-- For structure confirmation, write the confirmed lifecycle fields only after
-  the user confirms the structure proposal.
-- For no-write scope, emit a current `skip` or `unresolved[]` item only when the
-  current schema supports it and include the user-facing reason.
-- For conflict or weak evidence, repair the compile action, ask another
-  question, or return to structure confirmation.
-
-Do not invent confirmation fields. If the current schema has no place to record
-the answer, keep it in the user-facing handoff and stop before the write that
-would require it.
-
-## Grouping Questions
-
-You may group several questions only when they have the same business decision,
-same evidence strength, and same consequence. Do not group:
-
-- questions with different source boundaries;
-- one fact-level decision with one wording decision;
-- one item with evidence and another without evidence;
-- conflict resolution with no-write scope confirmation.
-
-When grouping is valid, ask one compact question listing each grouped claim and
-the plain-language evidence meaning. If the user confirms, apply the same
-current-surface confirmation to every grouped item. When in doubt, ask
-separately.
-
-## Self-verify
-
-- [ ] Every confirmed outcome maps to a specific current user answer.
-- [ ] The question described the business effect before any schema or command.
-- [ ] Structure/no-write confirmation was not inferred from generic approval.
-- [ ] Weak support was routed to structure confirmation, stronger evidence,
-  split sections, or unresolved handoff instead of compile-written body text.
-- [ ] Every no-write outcome for citation-eligible evidence has a reviewed skip,
-  unresolved item, or explicit user-facing handoff.
-- [ ] No unsupported evidence was accepted merely because the user allowed the
-  phase to continue.

package/plugins/codex/skills/continue/references/internal-procedures/skill-prose-compile/references/internal-procedures/semantic-judgment.md

@@ -1,194 +0,0 @@
----
-name: semantic-judgment
-description: >
-  Internal semantic repair procedure for the current source-bound compile and
-  review gates; not a user slash command. It judges support, duplicate/conflict
-  risk, scope fit, weak evidence, leakage, and user-confirmation needs, then
-  maps the result back to current structure, compile, review, or user-question
-  surfaces.
-tools:
-  - Bash
----
-
-# semantic-judgment
-
-Use this only when current compile validation, review diagnostics, or a review
-page asks for semantic repair beyond ordinary section drafting. This procedure
-does not define a separate write schema. The caller expresses the outcome
-through one of the current surfaces:
-
-- repair the `context.compile-actions.v1` payload;
-- return to `context.structure.v1` and mark the issue in `unresolved[]`;
-- ask the user a specific confirmation question;
-- leave the item unwritten with a source-backed reason.
-
-## TL;DR
-
-- Read only current CLI diagnostics and evidence views. Do not inspect
-  `sources/`, `unapproved/`, `knowledge/`, `dist/`, host tool results, or JSON
-  stdout fragments with generic tools.
-- Use this procedure for semantic support, duplicate/conflict, omit/scope,
-  leakage/ownership, temporal-prior, and confirmation questions.
-- Never invent facts to make a draft pass. If evidence is weak, either narrow the
-  claim, cite better source refs, return to structure confirmation, or ask the
-  user.
-- User confirmation must answer the specific current question. General
-  permission to continue is not confirmation.
-- Approval/apply is owned by the review gate. This procedure never runs an apply
-  command by itself.
-
-## Reference Routing
-
-| Situation | Reference |
-|---|---|
-| Current diagnostics report context-only or secondary ownership leakage | [semantic-judgment/references/leakage-and-ownership.md](semantic-judgment/references/leakage-and-ownership.md) |
-| Current diagnostics include source-ref boundary, temporal-prior, long content, or summary preservation issues | [semantic-judgment/references/temporal-and-evidence.md](semantic-judgment/references/temporal-and-evidence.md) |
-| You are considering not writing evidence that otherwise looks citation-eligible | [semantic-judgment/references/scope-review-and-omit.md](semantic-judgment/references/scope-review-and-omit.md) |
-| You are classifying unsupported, stale, replacement, withdrawal, or "remove" outcomes | [semantic-judgment/references/disposition-semantics.md](semantic-judgment/references/disposition-semantics.md) |
-| A weak-evidence or no-write decision needs explicit user confirmation | [semantic-judgment/references/user-confirmation.md](semantic-judgment/references/user-confirmation.md) |
-
-<reference>
-
-## Judgment Vocabulary
-
-Use this vocabulary in your repair explanation, user question, or current payload
-commentary. Do not emit it as a standalone schema unless the current CLI schema
-explicitly asks for matching fields.
-
-| Judgment | Meaning | Current route |
-|---|---|---|
-| `supported` | Cited source refs directly support the reader-facing claim. | Keep or repair the compile action. |
-| `weak` | Evidence plausibly supports a compression or interpretation, but a human should confirm the business meaning. | Ask the user, narrow/split the evidence boundary, or return to align. Do not add `content` / `content_intent`. |
-| `unsupported` | The claim adds facts, scope, terms, or conclusions absent from cited evidence. | Remove/narrow the action, cite stronger evidence, or return to structure. |
-| `duplicate` | Another planned or approved section already covers the same claim. | Skip this action with a clear reason or update the existing section only if the schema supports it. |
-| `separate` | The claim is distinct and source-backed. | Keep a separate action or planned section. |
-| `conflict` | The current claim and existing/planned knowledge disagree. | Ask the user or return to structure; do not auto-resolve. |
-| `structure_mismatch` | Evidence belongs under another node/section or needs a missing edge. | Return to prose align and revise confirmed structure. |
-
-## Decision Routing
-
-Semantic reconciliation is expressed only through the current compile/review
-gate. Route each judgment to the current flow:
-
-| Judgment shape | Current route |
-|---|---|
-| Exact same claim already active | Emit or repair a `skip` action with a duplicate reason. Do not write a second section. |
-| Same claim with source-backed correction or refinement | Use `update` only when the current compile schema and node-context expose the target section; otherwise ask the user or return to structure/review instead of silently merging. |
-| Additional but separate source-backed boundary | Keep a separate planned section/action when the confirmed structure owns the cited refs. |
-| New evidence replaces a previous rule | Stop and ask the user which rule should remain, or return to structure/review. Do not emulate replacement with a compile `update`. |
-| Direct contradiction | Ask the user. Do not auto-resolve, and do not rewrite approved knowledge from memory. |
-| Evidence is close but not enough | Ask the user, choose a narrower mirrorable ref, split the planned section, or return to align. Weak support is not permission to add missing facts. |
-| Useful but no-write / scope-wrong evidence | Run the Scope Review pass and require explicit user confirmation before treating citation-eligible evidence as no-write. |
-
-Do not emit standalone action names from another surface. Preserve the reasoning,
-then express the result through `context.compile-actions.v1`, `context.structure.v1`
-`unresolved[]`, review confirmation, or a user question.
-
-## Relation And Action Discipline
-
-Use the full semantic support / duplicate / conflict / disposition decision
-model, and map every outcome to a current route:
-
-| Prepared relation | Current action discipline |
-|---|---|
-| Exact duplicate | Skip/no-write only when the schema supports a reviewed skip or the current route says the item is already covered. |
-| Near duplicate / same claim with source-backed clarification | Prefer `update` only when the target section is exposed and the meaning does not change. |
-| Complementary separate claim | Keep separate when the confirmed planned section owns the refs and the claim is source-backed. |
-| Replacement / superseding claim | Stop for user or structure review. Current compile must not smuggle replacement through summarized body text or same-section update. |
-| Conflict | Ask the user a concrete business question. Do not resolve from source order, status order, or agent preference. |
-| Weak support | Ask for confirmation or mirror the source more directly; weak support never authorizes unsupported facts. |
-| Wrong node / wrong edge / wrong ownership | Return to prose align and revise `context.structure.v1`. Do not patch body text to compensate for a bad structure. |
-| Unsupported / source removed | Narrow or remove the proposed action. If approved knowledge disposition is needed, route to review/structure; compile does not physically remove approved content. |
-
-Do not accept a "default" semantic decision unless the current CLI explicitly
-states that the default is mechanically safe for the current item. A generic
-"continue" from the user is not a semantic default and is not user
-confirmation. Preserve candidate order and compare only candidates surfaced by
-the current CLI view; do not run your own workspace-wide search.
-
-## Evidence Boundary Gate
-
-A compile action must cite only source refs owned by the planned section it
-targets. If the proposed reader-facing claim cannot honestly be supported by
-those refs:
-
-1. Narrow the claim to what the refs support.
-2. Use a CLI-provided broader or adjacent ref only when the whole range supports
-   the final claim.
-3. Split unrelated facts into separate actions.
-4. Return to structure confirmation when the needed evidence belongs to another
-   node, another planned section, or an unresolved relation.
-
-Do not use titles, navigation lines, parent/child lists, or "related" hints as
-the sole support for a substantive claim.
-
-</reference>
-
-<procedures>
-
-### Step 1 — Consume Current Diagnostics
-
-Start from the current compile validation result, review HTML, or review/apply
-diagnostic. Identify:
-
-- the node and planned section involved;
-- the proposed action body, summary, kind, and source refs;
-- listed candidate sections or approved sections, if the view provides them;
-- whether the issue is support, duplicate/conflict, leakage, scope, or user
-  confirmation.
-
-If the current CLI provides detail or pagination commands, follow them before
-judging. Do not discover extra candidates by searching files yourself.
-
-### Step 2 — Judge Support
-
-Compare the reader-facing claim against cited source evidence:
-
-- Every sentence must be supported by at least one cited ref.
-- Summary may compress, but it must not introduce a new fact.
-- Summary must stay faithful to source terms, numbers, code literals, product
-  names, and relationship direction.
-- Compile actions do not carry reader-facing `content`. If the section body can
-  mirror source text, omit `content` and let the CLI materialize it verbatim.
-  If it cannot mirror one confirmed evidence boundary, split or return to align.
-
-Classify as `supported`, `weak`, or `unsupported`, then repair using the route in
-the vocabulary table.
-
-### Step 3 — Judge Relation To Existing Or Planned Knowledge
-
-Use only candidates surfaced by the current CLI view. Do not run workspace-wide
-searches.
-
-- Same claim already covered -> skip the duplicate action or update through the
-  current compile schema if it explicitly supports that operation.
-- Related but distinct source-backed claim -> keep it separate.
-- Replacement or contradiction -> ask the user or return to structure/review;
-  do not silently overwrite approved knowledge, and do not turn replacement into
-  a same-section edit.
-- Missing node, wrong ownership, or wrong relationship -> return to prose align.
-
-### Step 4 — Ask The User Only When Needed
-
-Ask a user question when business meaning, conflict resolution, weak support, or
-no-write scope cannot be decided from evidence. The question must name the
-business choice, not internal source-ref ids.
-
-After the user answers, express the answer through the current surface:
-
-- lifecycle confirmation for structure;
-- a repaired compile action;
-- an `unresolved[]` item;
-- a skipped action with an explicit source-backed reason.
-
-### Step 5 — Self-verify
-
-- [ ] Only current phase commands and schemas were used.
-- [ ] Only fields accepted by the current schema view were emitted.
-- [ ] Every kept claim is supported by current source refs.
-- [ ] Every no-write outcome has an explicit reason or user confirmation when
-  the evidence was otherwise citation-eligible.
-- [ ] Structure defects return to prose align instead of being hidden in compile.
-- [ ] Apply/approval remains in the review gate.
-
-</procedures>