feat(spec): v0.7.4 — manifest extensions lane

[tymofiy]

Summary

Adds an optional extensions object at the PACK.yaml manifest root as the sanctioned compatibility lane for experimental or implementation-specific metadata. The manifest root stays closed (additionalProperties: false); experimental fields belong under extensions, not at the top level.

Why

The spec currently has no sanctioned way to ship experimental manifest metadata without either:

• breaking additionalProperties: false at the root (rejected — the closed root is load-bearing), or
• promoting an unproven field into the core schema.

This PR introduces a narrow third path. Consumers MUST ignore unknown extension content. Extensions MUST NOT redefine core semantics. Tools can ship experiments without forcing a schema break or prematurely promoting a payload into the core standard.

Changed

• spec/CHANGELOG.md — v0.7.4 entry (Added / Changed)
• spec/CORE.md — Manifest Extensions prose + field table row + illustrative framing
• spec/SPEC.md — new §3.2 Manifest Extensions section + YAML example
• conformance/grammar/kp-pack.schema.json — extensions property; root remains closed

Illustrative example

The spec uses one payload to make the lane concrete:

extensions:
  ai_brief:
    version: 1
    verdict: acceptable
    headline: "Strong base attribution, but provenance gap remains"

The spec explicitly frames this as illustrative only — extension names and shapes are defined by their producers, not by KP:1.

Judgment call — ai_brief as the public example

Whether to keep ai_brief (a real internal concept already consumed by the viewer) or invent a generic placeholder was consulted across two independent models. Split opinion:

• One position: invent a placeholder, cite RFC 6648 / Hyrum's Law — third parties will mirror the shape regardless of disclaimer.
• Other position: keep it with explicit "illustration only" framing, cite OpenAPI vendor-extension precedent where real examples + registry/disclaimer is the canonical pattern.

Decision: keep ai_brief, but strengthen the "illustrative only, producer-defined" framing in both CORE.md prose and SPEC.md example comment. This threads the dissent without losing the motivating concreteness.

Section numbering

Initial pass placed Manifest Extensions at §3.1, which pushed Channels to §3.2 and invalidated two existing §3.1 cross-references in SPEC.md (lines 227 and 1329). Corrected by placing Manifest Extensions at §3.2 instead, so Channels keeps §3.1 and cross-references stay valid.

Downstream impact — verified

• kp-viewer (PackLoader.swift:142–193, 172–177, 211–213) — already parses extensions.ai_brief and ignores unknown top-level fields. v0.7.4 describes what the viewer already consumes. No viewer code change required.
• kp-forge (serialize.ts:1181, types.ts:443, assemble.ts:88) — already emits extensions.ai_brief. No sealer change required.
• kp-packs relay — doesn't touch the extensions surface. Transparent.
• intel / providers — doesn't touch manifest schema. Transparent.
• Existing packs in repos/packs — all 54 manifests validate against the updated schema. Zero migration.

In other words: v0.7.4 is the spec catching up to what the tooling already produces. No coordinated downstream rollout is required.

Verified locally

• lefthook run pre-commit — all rules pass
• python3 conformance/run.py — 12/12 pass
• markdownlint '**/*.md' — clean
• Cross-refs (§3.1 Channels still resolves; Extensions is §3.2)

[Copilot]

Pull request overview

Adds a sanctioned “manifest extensions lane” to KP:1 by introducing an optional extensions object at the PACK.yaml root, preserving a closed manifest root (additionalProperties: false) while enabling experimental/implementation-specific metadata.

Changes:

• Adds extensions guidance + examples to the spec docs (CORE.md, SPEC.md) and records the change in the changelog (v0.7.4).
• Extends the normative PACK.yaml JSON Schema to allow an extensions object while keeping the root closed.
• Tightens lefthook deny-list regexes (stacked from #8).

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
spec/SPEC.md	Documents the extensions lane and adds an illustrative manifest example + new §3.2 section.
spec/CORE.md	Adds extensions to the Core Optional Fields table and provides normative guidance + examples.
spec/CHANGELOG.md	Adds v0.7.4 entry describing the manifest extensions lane.
lefthook.yml	Updates deny-list grep patterns (process-language detection).
conformance/grammar/kp-pack.schema.json	Adds extensions as an allowed top-level object; keeps root additionalProperties: false.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The pattern reviewer [0-9]+\b is using \b as a word-boundary, but grep -E does not portably support \b as a word-boundary (often treated as backspace). This can make the deny-list miss matches like reviewer 12 on some environments. Use a POSIX-compatible boundary (e.g., reviewer [0-9]+([^0-9]|$)) or switch to grep -P if you want \b semantics.

Suggested change

	if grep -inE 'cross-model (review|consultation|spec review)|multi-model (synthesis|analysis|consultation|spec review)|three-model consultation|two-model consultation|round [0-9]+ (review|verify|cross-model|findings)|consulted (codex|gemini|claude)|adversarial review|(codex|gemini|claude) feedback|reviewer [0-9]+\b|session handover|model attributions' "$file" 2>/dev/null; then
	if grep -inE 'cross-model (review|consultation|spec review)|multi-model (synthesis|analysis|consultation|spec review)|three-model consultation|two-model consultation|round [0-9]+ (review|verify|cross-model|findings)|consulted (codex|gemini|claude)|adversarial review|(codex|gemini|claude) feedback|reviewer [0-9]+([^0-9]|$)|session handover|model attributions' "$file" 2>/dev/null; then

[Copilot]

Same issue as pre-commit: grep -iE with reviewer [0-9]+\b is not portable because \b isn't reliably a word-boundary in ERE. This can weaken the commit-msg deny-list (false negatives). Prefer a POSIX-safe boundary like reviewer [0-9]+([^0-9]|$) or use grep -P if PCRE is acceptable.

Suggested change

	if echo "$clean" | grep -iE 'cross-model|multi-model (synthesis|analysis|consultation|review)|round [0-9]+ (review|verify|findings)|consulted (codex|gemini|claude)|(codex|gemini|claude) (feedback|suggested|reviewed)|adversarial review|reviewer [0-9]+\b|session handover|model attributions' >/dev/null 2>&1; then
	if echo "$clean" | grep -iE 'cross-model|multi-model (synthesis|analysis|consultation|review)|round [0-9]+ (review|verify|findings)|consulted (codex|gemini|claude)|(codex|gemini|claude) (feedback|suggested|reviewed)|adversarial review|reviewer [0-9]+([^0-9]|$)|session handover|model attributions' >/dev/null 2>&1; then

[Copilot]

extensions is now part of the normative schema, but none of the conformance fixtures currently exercise it (including valid/maximal.kpack, which is documented as covering every optional PACK.yaml field). Add an extensions object to the maximal fixture (and optionally an invalid fixture where extensions is non-object) to keep schema coverage claims accurate and prevent regressions.