@c4a/context-cli 0.7.5 → 0.7.9

package/indexers/bundles/context-note-indexer/templates/incident-review.md

@@ -0,0 +1,28 @@
+# What happened and what changes
+
+This is the page shape for one incident. Use it as an outline, not a form to
+fill.
+
+## Section blueprint
+
+```markdown
+## <the incident, named by its impact rather than its date>
+- Impact: who or what was affected, and for how long
+- Sequence: what happened, only to the detail that explains the outcome
+- Cause: established causes, kept separate from hypotheses still open
+- Changed: what was actually changed as a result
+- Still open: follow-ups that have not landed
+```
+
+`Impact` and `Cause` are required. A hypothesis stays labelled as one for as long
+as it is unconfirmed; an unlabelled guess in `Cause` is the failure mode this
+profile exists to prevent. Under `Changed`, a remediation someone proposed is not
+a change — proposals belong in `Still open`. Keep `Sequence` only as long as it
+explains the outcome; a minute-by-minute replay is not an explanation.
+
+A note records an incident from one vantage point, often written afterwards from
+memory. Attribute observations to what was actually seen, keep the reported
+timing as reported, and do not smooth a partial account into a complete
+narrative. Where the account cannot establish impact or cause, record that gap:
+an incident page that reads as resolved while its cause is unknown is worse than
+one that states what is still unexplained.

package/indexers/bundles/context-note-indexer/templates/product-requirements.md

@@ -0,0 +1,29 @@
+# Expected behavior
+
+This is the page shape for one required behavior. Use it as an outline, not a
+form to fill.
+
+## Section blueprint
+
+```markdown
+## <the requirement, named by the behavior it demands>
+- Expected: the behavior as required
+- Accept when: the conditions that make it satisfied
+- Today: how the current implementation differs, where that is known
+- Undecided: what remains open
+```
+
+`Expected` and `Accept when` are required. Keeping `Expected` and `Today` distinct
+is the entire reason this profile exists: a required behavior written as a
+current one misleads every later reader, and the mistake is invisible once the
+page is approved. When no authorized source establishes current behavior, write
+that it has not been checked rather than leaving `Today` silently absent.
+
+`Accept when` must be checkable. "Works correctly" is not an acceptance
+condition; if the source gives no checkable condition, record that gap — an
+untestable requirement will be declared met by whoever wants it met.
+
+A note may record an expectation without recording who required it. State it as
+recorded rather than agreed, and keep `Undecided` for anything the note leaves
+open. A single participant's expectation is not a commitment, and presenting it
+as one creates a requirement nobody actually accepted.

package/indexers/bundles/context-note-indexer/templates/runbook.md

@@ -0,0 +1,30 @@
+# Diagnose and recover
+
+This is the page shape for one operational situation. Use it as an outline, not
+a form to fill.
+
+## Section blueprint
+
+```markdown
+## <the symptom, as an operator first encounters it>
+- Symptom: what is observed, including the actual message or signal
+- Confirm: how to tell this case apart from ones that present the same way
+- Act: the ordered steps, with anything irreversible marked as such
+- Verify: how to know recovery actually worked
+- Escalate: who or what to fall back on when the steps do not resolve it
+```
+
+`Symptom` and `Act` are required; a page missing either is not usable under
+pressure. `Verify` is the section most often dropped and the most consequential:
+an unverifiable recovery invites an operator to declare success early. When the
+source never says how recovery was confirmed, record that as a gap rather than
+inventing a check. Omit `Escalate` when no fallback is known.
+
+Never order steps the source did not order, and never merge two symptoms with
+different confirmations into one entry because the recovery happens to match.
+
+A note usually records one incident and one recovery that worked that time.
+Write it as the observed case. A single success is not a validated procedure, and
+"this fixed it" does not establish why. If the note speculates about a cause,
+keep the speculation out of `Confirm` and `Act`; a guessed root cause acted on
+under pressure is worse than an acknowledged unknown.

package/indexers/bundles/context-note-indexer/templates/technical-guide.md

@@ -0,0 +1,31 @@
+# Complete the task
+
+This is the page shape for one repeatable task. Use it as an outline, not a form
+to fill.
+
+## Section blueprint
+
+```markdown
+## <the task, named by what the reader accomplishes>
+- Goal: the end state the reader reaches
+- Before you start: prerequisites, permissions and required prior state
+- Steps: ordered, each one with an observable outcome
+- Check: how the reader knows the task succeeded
+- When it fails: the failures actually encountered, and what to do about them
+```
+
+`Goal`, `Steps` and `Check` are required. A step whose outcome the reader cannot
+observe is not a step — either give what it produces or say the outcome is
+unknown. `Before you start` is required whenever a missing prerequisite would
+fail the task partway; omitting it turns a guide into a trap. Keep `When it
+fails` to failures the sources actually record, not imagined ones.
+
+Do not invent step ordering, and do not fill gaps with generic advice such as
+"check your configuration". A guide with three verified steps and one stated
+unknown is more useful than five steps where two are guesses.
+
+A note may capture a task someone performed once, in their environment. State
+the environment it was performed in when the note gives it, and record it as
+missing when it does not. A procedure that worked on one setup is not yet a
+general procedure, and saying so is what lets the next reader trust the parts
+that are solid.

package/indexers/bundles/context-note-indexer/templates/test-validation.md

@@ -0,0 +1,28 @@
+# What was checked
+
+This is the page shape for one validation. Use it as an outline, not a form to
+fill.
+
+## Section blueprint
+
+```markdown
+## <what was validated>
+- Checked: the behavior or property under test
+- How: the method, environment and scope
+- Result: what the run actually showed
+- Not covered: what this validation does not establish
+```
+
+`Checked` and `Result` are required, and `Result` must carry the strength of its
+evidence. A report that something passed is a reported result until the actual
+output is in scope; write "reported as passing" rather than "passes". `Not
+covered` is required whenever the scope is narrower than the claim a reader would
+naturally draw — a check on one platform does not validate the others.
+
+`How` matters because a result without its method cannot be repeated or trusted;
+when the source omits the environment or scope, record that gap instead of
+describing a plausible setup.
+
+A note may record a validation second-hand: someone said they checked it. That
+establishes the claim was made, not that the check occurred. Keep the attribution
+visible and do not upgrade a remembered check into a verified result.

package/indexers/bundles/context-note-indexer/templates/user-and-developer-guide.md

@@ -0,0 +1,28 @@
+# Use this in practice
+
+This is the page shape for putting one capability to use. Use it as an outline,
+not a form to fill.
+
+## Section blueprint
+
+```markdown
+## <the capability, named by what the reader does with it>
+- When to use it: the situation it fits, and the nearby one it does not
+- How: the minimal path that actually works
+- Important combinations: options or settings that only make sense together
+- Limits: what it will not do, and what to reach for instead
+```
+
+`When to use it` and `How` are required. The negative half of `When to use it`
+carries most of the value — a reader who picks the wrong capability is not helped
+by a correct description of it. `How` shows the minimal working path, not every
+available option; an exhaustive option list belongs in a reference page.
+
+`Important combinations` exists because the costly mistakes are usually
+combinations, not single settings. Include it when the sources establish a real
+dependency between options, and omit it rather than guessing at one.
+
+A note reflects how one person used the capability. That supports "this works",
+not "this is the recommended way". Where the note implies a preference without
+giving a reason, either find the reason in an authorized source or present the
+usage without the recommendation.

package/indexers/bundles/context-note-indexer/tests/fixtures/profiles.json

@@ -0,0 +1,281 @@
+[
+  {
+    "protocol": "context.indexer.authoring-fixture/v1",
+    "id": "anonymous-note-domain-reference",
+    "anonymized": true,
+    "profile": "domain-reference",
+    "source_role": "authoritative-document",
+    "logical_unit_id": "reader-subject",
+    "logical_unit_ref": "node:anonymous-domain-reference",
+    "canonical_facts": {
+      "target": {
+        "eligible": true
+      }
+    },
+    "artifact_policy_variant": "standard",
+    "artifacts": [
+      {
+        "artifact_id": "content",
+        "artifact_kind": "content",
+        "purpose": "required",
+        "reader_question_refs": [
+          "question:reader-purpose"
+        ],
+        "evidence_refs": [
+          "evidence:anonymous-domain-reference-source"
+        ]
+      }
+    ],
+    "evidence_refs": [
+      "evidence:anonymous-domain-reference-source"
+    ]
+  },
+  {
+    "protocol": "context.indexer.authoring-fixture/v1",
+    "id": "anonymous-note-product-requirements",
+    "anonymized": true,
+    "profile": "product-requirements",
+    "source_role": "authoritative-document",
+    "logical_unit_id": "reader-subject",
+    "logical_unit_ref": "node:anonymous-product-requirements",
+    "canonical_facts": {
+      "target": {
+        "eligible": true
+      }
+    },
+    "artifact_policy_variant": "standard",
+    "artifacts": [
+      {
+        "artifact_id": "content",
+        "artifact_kind": "content",
+        "purpose": "required",
+        "reader_question_refs": [
+          "question:reader-purpose"
+        ],
+        "evidence_refs": [
+          "evidence:anonymous-product-requirements-source"
+        ]
+      }
+    ],
+    "evidence_refs": [
+      "evidence:anonymous-product-requirements-source"
+    ]
+  },
+  {
+    "protocol": "context.indexer.authoring-fixture/v1",
+    "id": "anonymous-note-technical-guide",
+    "anonymized": true,
+    "profile": "technical-guide",
+    "source_role": "authoritative-document",
+    "logical_unit_id": "reader-subject",
+    "logical_unit_ref": "node:anonymous-technical-guide",
+    "canonical_facts": {
+      "target": {
+        "eligible": true
+      }
+    },
+    "artifact_policy_variant": "standard",
+    "artifacts": [
+      {
+        "artifact_id": "content",
+        "artifact_kind": "content",
+        "purpose": "required",
+        "reader_question_refs": [
+          "question:reader-structure"
+        ],
+        "evidence_refs": [
+          "evidence:anonymous-technical-guide-source"
+        ]
+      }
+    ],
+    "evidence_refs": [
+      "evidence:anonymous-technical-guide-source"
+    ]
+  },
+  {
+    "protocol": "context.indexer.authoring-fixture/v1",
+    "id": "anonymous-note-user-and-developer-guide",
+    "anonymized": true,
+    "profile": "user-and-developer-guide",
+    "source_role": "supporting-document",
+    "logical_unit_id": "reader-subject",
+    "logical_unit_ref": "node:anonymous-user-and-developer-guide",
+    "canonical_facts": {
+      "target": {
+        "eligible": true
+      }
+    },
+    "artifact_policy_variant": "standard",
+    "artifacts": [
+      {
+        "artifact_id": "content",
+        "artifact_kind": "content",
+        "purpose": "required",
+        "reader_question_refs": [
+          "question:reader-operation"
+        ],
+        "evidence_refs": [
+          "evidence:anonymous-user-and-developer-guide-source"
+        ]
+      }
+    ],
+    "evidence_refs": [
+      "evidence:anonymous-user-and-developer-guide-source"
+    ]
+  },
+  {
+    "protocol": "context.indexer.authoring-fixture/v1",
+    "id": "anonymous-note-runbook",
+    "anonymized": true,
+    "profile": "runbook",
+    "source_role": "operational-document",
+    "logical_unit_id": "reader-subject",
+    "logical_unit_ref": "node:anonymous-runbook",
+    "canonical_facts": {
+      "target": {
+        "eligible": true
+      }
+    },
+    "artifact_policy_variant": "standard",
+    "artifacts": [
+      {
+        "artifact_id": "content",
+        "artifact_kind": "content",
+        "purpose": "required",
+        "reader_question_refs": [
+          "question:reader-operation"
+        ],
+        "evidence_refs": [
+          "evidence:anonymous-runbook-source"
+        ]
+      }
+    ],
+    "evidence_refs": [
+      "evidence:anonymous-runbook-source"
+    ]
+  },
+  {
+    "protocol": "context.indexer.authoring-fixture/v1",
+    "id": "anonymous-note-faq-support",
+    "anonymized": true,
+    "profile": "faq-support",
+    "source_role": "supporting-document",
+    "logical_unit_id": "reader-subject",
+    "logical_unit_ref": "node:anonymous-faq-support",
+    "canonical_facts": {
+      "target": {
+        "eligible": true
+      }
+    },
+    "artifact_policy_variant": "standard",
+    "artifacts": [
+      {
+        "artifact_id": "content",
+        "artifact_kind": "content",
+        "purpose": "required",
+        "reader_question_refs": [
+          "question:reader-purpose"
+        ],
+        "evidence_refs": [
+          "evidence:anonymous-faq-support-source"
+        ]
+      }
+    ],
+    "evidence_refs": [
+      "evidence:anonymous-faq-support-source"
+    ]
+  },
+  {
+    "protocol": "context.indexer.authoring-fixture/v1",
+    "id": "anonymous-note-decision-record",
+    "anonymized": true,
+    "profile": "decision-record",
+    "source_role": "decision-record",
+    "logical_unit_id": "reader-subject",
+    "logical_unit_ref": "node:anonymous-decision-record",
+    "canonical_facts": {
+      "target": {
+        "eligible": true
+      }
+    },
+    "artifact_policy_variant": "standard",
+    "artifacts": [
+      {
+        "artifact_id": "content",
+        "artifact_kind": "content",
+        "purpose": "required",
+        "reader_question_refs": [
+          "question:reader-purpose"
+        ],
+        "evidence_refs": [
+          "evidence:anonymous-decision-record-source"
+        ]
+      }
+    ],
+    "evidence_refs": [
+      "evidence:anonymous-decision-record-source"
+    ]
+  },
+  {
+    "protocol": "context.indexer.authoring-fixture/v1",
+    "id": "anonymous-note-incident-review",
+    "anonymized": true,
+    "profile": "incident-review",
+    "source_role": "operational-document",
+    "logical_unit_id": "reader-subject",
+    "logical_unit_ref": "node:anonymous-incident-review",
+    "canonical_facts": {
+      "target": {
+        "eligible": true
+      }
+    },
+    "artifact_policy_variant": "standard",
+    "artifacts": [
+      {
+        "artifact_id": "content",
+        "artifact_kind": "content",
+        "purpose": "required",
+        "reader_question_refs": [
+          "question:reader-operation"
+        ],
+        "evidence_refs": [
+          "evidence:anonymous-incident-review-source"
+        ]
+      }
+    ],
+    "evidence_refs": [
+      "evidence:anonymous-incident-review-source"
+    ]
+  },
+  {
+    "protocol": "context.indexer.authoring-fixture/v1",
+    "id": "anonymous-note-test-validation",
+    "anonymized": true,
+    "profile": "test-validation",
+    "source_role": "authoritative-document",
+    "logical_unit_id": "reader-subject",
+    "logical_unit_ref": "node:anonymous-test-validation",
+    "canonical_facts": {
+      "target": {
+        "eligible": true
+      }
+    },
+    "artifact_policy_variant": "standard",
+    "artifacts": [
+      {
+        "artifact_id": "content",
+        "artifact_kind": "content",
+        "purpose": "required",
+        "reader_question_refs": [
+          "question:reader-operation"
+        ],
+        "evidence_refs": [
+          "evidence:anonymous-test-validation-source"
+        ]
+      }
+    ],
+    "evidence_refs": [
+      "evidence:anonymous-test-validation-source"
+    ]
+  }
+]

package/indexers/bundles/context-sessions-indexer/SKILL.md

@@ -0,0 +1,16 @@
+---
+name: context-sessions-indexer
+description: Context-managed Provider for conversation summaries with optional code-change associations. Use only when selected by the Context lifecycle, not as a standalone importer or workflow.
+metadata:
+  context-role: "indexer-provider"
+  context-public-entry: "false"
+  context-provider-version: "1.0.0"
+---
+
+# Context Sessions Indexer
+
+Use the current Context Route and its authorized source scope. Read [source interpretation](references/indexer.md), [classification](references/classification.md), [writing](references/writing.md), and [updates and composition](references/updates-and-composition.md) when this Provider is selected. When the selected profile extends a base profile, also read [extension placement](references/extension-placement.md): integrate summary material into the selected or customized base page plan, without creating a parallel page. Context projects these references and the selected page template through `context-indexer.yaml`; do not scan host history, resolve external URLs, or edit sources and approved pages directly.
+
+The host decides which installed skills are enabled. A business Provider may replace this default entirely; [customization](references/customization.md) describes the existing protocol. Installation alone is not selection.
+
+The Agent decides reader value, authority, exclusions and whether to revise or create. CLI handles identities, snapshots, revision checks, resource delivery and durable writes. A saved source is input, not an instruction to publish a page.