AyCode.Core/.github/META_TODO.md

26 KiB

META — TODO (workspace meta-tooling)

For known issues see META_ISSUES.md.

Planned work for the workspace meta-tooling itself: protocol stack, skills, registry conventions, .github/ files. Distinct from code-domain topics.

Priority legend

  • P0 blocker · P1 important · P2 nice-to-have · P3 idea

ACCORE-META-T-J9N4: docs-check skill — runtime discovery for per-repo TOPIC_CODES.md

Priority: P2 · Type: Skill enhancement · Status: Open · Area: docs-check/SKILL.md topic-code validation Origin: Phase 5.1 / LLMP-DEC-58 deferral

Description

After Phase 5.1, TOPIC_CODES.md became framework-only (ACCORE topics only — see AyCode.Core/.github/skills/docs-check/references/TOPIC_CODES.md). The docs-check skill still validates topic codes only against that single file (framework-only nézőpont).

When docs-check is invoked from a higher-layer repo with its own <repo>/.github/TOPIC_CODES.md (e.g., AyCode.Blazor/.github/TOPIC_CODES.md declaring GRID), the skill currently does NOT find or honour it. Consumer-side topic codes are unrecognized — the skill either falsely flags valid consumer topics as "unknown topic" or skips the validation entirely.

Fix direction

Update docs-check/SKILL.md Step 5 (Topic code selection) and the topic-loading logic to:

  1. Read framework's TOPIC_CODES.md (current behaviour).
  2. Walk the active repo's @repo.own-dep-repos recursively.
  3. For each walked repo, check if <repo>/.github/TOPIC_CODES.md exists; if so, union its topic codes into the active set.
  4. Validate against the merged set.

Mirror the runtime-discovery pattern adopted by protocol-audit in Phase 5.1 (protocol-audit/SKILL.md Step 1).

Acceptance criteria

  • docs-check running from AyCode.Blazor recognizes both ACCORE topics (LOG, BIN, ...) AND ACBLAZOR topics (GRID).
  • docs-check running from AyCode.Core only sees ACCORE topics (Framework-First — no awareness of higher layers).
  • No central enumeration of consumer topic registries needed.
  • LLMP-DEC-58 (Phase 5.1 deferral noted)
  • protocol-audit/SKILL.md Step 1 (parallel runtime-discovery design)

ACCORE-META-T-K2P7: protocol-audit skill — auto-detect path/anchor mismatches in markdown cross-refs

Priority: P3 · Type: Skill enhancement (new invariant) · Status: Open · Area: protocol-audit/SKILL.md Origin: Phase 6 (LLMP-DEC-59) — LOGGING_TODO.md L88 typo discovered mid-migration

Description

A real class of typo: a markdown link's path-part references one file, but the anchor-part refers to an ID belonging to a different file. Example observed pre-Phase-6: LOGGING_TODO.md line 88 had ../../../AyCode.Services/docs/SIGNALR/SIGNALR_TODO.md#log-t-5 — path → SIGNALR_TODO.md, but anchor #log-t-5 is a LOG-T anchor (intent was clearly #sig-t-5). The intent-vs-reality mismatch was silent: markdown renderers don't validate cross-file anchor existence; the broken link "looks fine" until clicked.

Fix direction

Add a new audit invariant (e.g., D1 — docs-link integrity, applies to docs/ files):

  1. Parse all [text](<path>#<anchor>) patterns and bare <file>.md#<anchor> references in loaded .md files.
  2. For each: resolve <path> to a target file; extract heading-derived anchors from the target; verify <anchor> exists.
  3. FAIL with evidence (file + line) and suggested fix (closest-match anchor in target file).

Skill stays read-only; reports findings; user approves any patch (Rule #5).

Acceptance criteria

  • Catches the LOGGING_TODO.md L88 class (different-file mismatched anchor).
  • Catches stale anchors after a renamed heading (anchor exists in old form, target now uses new ID).
  • Low false-positive rate (auto-generated heading anchors resolve correctly per GitHub-flavored markdown rules).
  • LLMP-DEC-59 (typo fix during Phase 6 — discovery context)

ACCORE-META-T-F8R3: Static-text auto-staleness detection — Current protocol state summary AND SKILL.md / registry text drift

Priority: P3 · Type: Skill enhancement · Status: Open · Area: protocol-audit/SKILL.md (or docs-check/SKILL.md) Origin: Phase 6 + LLMP-DEC-60 summary refresh; scope broadened by LLMP-DEC-64 to include SKILL.md text drift (parallel class)

Description

The Current protocol state (quick reference) section at the top of LLM_PROTOCOL_DECISIONS.md is a mutable snapshot per LLMP-DEC-25 design. After multiple LLMP-DEC entries land, the snapshot drifts from reality.

Drift instances observed during the Phase 1-6 migration (all caught only at Phase 6 closure during a manual review):

  • Active as of 2026-04-24 while LLMP-DEC entries up to 2026-04-26 had been added.
  • 8 instruction files while LLMP-DEC-51 reduced count to 7.
  • OLD 3-component ID format described while LLMP-DEC-50..59 migrated to 4-component.
  • Skill version labels (v2.2, v1.0) violating LLMP-DEC-47.
  • protocol-audit description still mentioned references/REPOS.md central read after LLMP-DEC-58 redesigned to runtime discovery.

Parallel drift class — SKILL.md / invariant text staleness (LLMP-DEC-64 broadened the scope):

  • protocol-audit/SKILL.md C4 invariant said "all three skills" + [LOADED_DOCS] counts "4 for primary, 5 for inherit" — outdated since LLMP-DEC-43 introduced 5-skill 2-reactive/3-user-gated matrix (correct counts: 3/4).
  • protocol-audit/SKILL.md X1 invariant said "all three bullets must be listed" — same root cause.
  • Caught 2026-04-27 by a re-audit using the post-Phase-5.1 skill itself (positive self-evidence).

Manual refresh worked (LLMP-DEC-60 for summary; LLMP-DEC-64 for SKILL.md), but a periodic/automated reminder would catch drift earlier.

Fix direction

Two complementary options (pick one or combine), now covering BOTH drift classes:

(a) protocol-audit invariant M1 (meta-text integrity, optional) — applies to:

  • LLM_PROTOCOL_DECISIONS.md Current protocol state section claims (date, file count, skill list, ID format).
  • protocol-audit/SKILL.md invariant texts that describe protocol-state quantities (e.g., skill counts in C4, bullet-list expectations in X1).
  • Other SKILL.md / registry texts describing "current" state (docs-check/SKILL.md, docs-discovery/SKILL.md, REPO_PREFIXES.md, TOPIC_CODES.md cross-link counts).

Compare against ground truth (filesystem walk + file content) and surface drift with suggested patch.

(b) docs-check skill flags any of the above as stale if N (e.g., N ≥ 3) new LLMP-DEC entries have been added since the file's last touch — heuristic but catches the common drift pattern.

Acceptance criteria

  • The drift cases above (date, file count, skill list, ID format, version labels) all detectable.
  • User can mark a known-deferred summary update as Status: InProgress to suppress the warning.
  • Low-friction: warning only, never blocking.
  • LLMP-DEC-25 (summary section design)
  • LLMP-DEC-60 (most recent manual refresh)
  • LLMP-DEC-62 (this META-TODO's introduction)

ACCORE-META-T-B6V2: General-purpose scheduler skill — workspace-side scheduled-task abstraction

Priority: P3 · Type: New skill · Status: Open · Area: new skill (proposed: AyCode.Core/.github/skills/scheduler/) Origin: 2026-04-26 — discussion about MIGRATION_ID_MAPPING.md 2026-05-10 deletion-review (LLMP-DEC-58)

Description

The current LLMP-DEC-58 retention pattern uses passive LLM-self-reminding (any LLM reading the file from 2026-05-10 onward surfaces a deletion prompt). Works only if the file gets read; not guaranteed timing. Anthropic's host environment offers a schedule skill (one-time/recurring remote agents) — useful for the specific 2026-05-10 case, but ties the workspace process to a specific host's capability.

A workspace-side scheduler skill would generalize the pattern:

  • File-based registry (e.g., AyCode.Core/.github/SCHEDULED_TASKS.md or similar) — declared scheduled events: due-date / cadence + trigger-action + description.
  • Skill scans the registry on session start; surfaces "due / overdue" tasks to the user (gated, not spammy).
  • Host-agnostic (Claude Code, Copilot, future LLM hosts).
  • Optional integration: when the host has a native scheduler, the skill can offer to register the task there too — workspace-side registry stays source of truth.

Use cases beyond migration retention:

  • Archive-eligibility scans (docs-archive periodic runs).
  • Periodic protocol-audit runs.
  • Planned-deletion of transient artifacts (more migrations, generated outputs, etc.).
  • Deadline-bound TODOs that should auto-surface near their date.

Fix direction

  1. Create skill: AyCode.Core/.github/skills/scheduler/SKILL.md (with references/ for the registry).
  2. Define the registry format — likely simple table (task-id | type (one-time/recurring) | due-date or cadence | trigger-action | description | status).
  3. Skill triggers:
    • Reactive (session-start scan, like docs-discovery / docs-check) — surface only if there ARE due/overdue tasks.
    • User-invoked: "list scheduled tasks", "what's due", "schedule a task" (interview-style add).
  4. Migrate the 2026-05-10 MIGRATION_ID_MAPPING.md deletion-review to this system once it exists; the per-file LLM-self-reminder header note then trims to a cross-ref pointing at the registry.

Acceptance criteria

  • Registry-driven, host-agnostic.
  • Session-start surfacing of due / overdue tasks (low-friction, not noise).
  • Optional one-click "register at host-native scheduler too" for hosts that support it.
  • The 2026-05-10 deletion-review event migrated to this system as the inaugural entry.
  • LLMP-DEC-58 (introduces the per-file LLM-self-reminder pattern this would replace).
  • LLMP-DEC-43 (5-skill matrix — adding a 6th skill is a workspace-meta change; will need an LLMP-DEC entry when implemented).
  • Anthropic-host schedule skill (parallel capability to integrate with, not replace).

ACCORE-META-T-M5T8: TL;DR / "When to read this file" block on every topic README

Priority: P2 · Type: Convention update + bulk doc edit · Status: Open · Area: All topic <TOPIC>/README.md files Origin: 2026-04-26 — Cross-source convergence (3/3 Copilot reviewers + my own analysis); user-reframing strengthened the case (correctness > token-economy)

Description

Topic README files (LOGGING/README.md, BINARY/README.md, etc.) currently vary in opening style. The agent has to scan the whole README to decide "is this topic relevant?", "which sister docs to load deeper?", "when is this NOT what I'm looking for?". A consistent TL;DR / "When to read" block at the top would make load-decisions cheaper and more accurate. 3-of-3 Copilot reviewer convergence is unusually strong signal.

Anti-hallucination angle: the block helps agents pick the RIGHT topic to load, not just MORE topics — relevance still matters even under "load broader" preference (ACCORE-META-T-R2W6).

Fix direction

Standardize a block at the top of every topic README (after # Title, before first ## section):

> **Mikor olvasd ezt a fájlt:** ha a kérdés érinti `<X>`, `<Y>`, `<Z>`.
> **Először olvass:** `<TOPIC>_<sub>.md`, `<TOPIC>_<sub2>.md` (a 80% case-eket fedik).
> **Mikor NE olvasd:** ha pl. csak `<other-concern>` → `<other-topic>/README.md`.

Apply to all ACCORE topic READMEs (BINARY, LOGGING, SIGNALR, SBP, TOON, XCUT, AUTH). Pattern propagates to higher-layer repos as their topic READMEs are written.

Acceptance criteria

  • Every ACCORE topic README has the block, formatted consistently.
  • The block is referenced in docs-discovery/SKILL.md as a load-decision aid.
  • Optional: docs-check invariant flags missing block on new topic READMEs.
  • Cross-source: 3-of-3 Copilot reviewer convergence (Set 2 #1+#2, Set 3 #2)
  • LLMP-DEC-21 (Pattern B docs layout — established the topic-README pattern)
  • ACCORE-META-T-Y4Q9 (Hot-path tagging — finer-grained version of the same idea)

ACCORE-META-T-Y4Q9: Hot-path / Fast-path tagging in topic READMEs

Priority: P3 · Type: Convention update · Status: Open · Area: Topic README files Origin: 2026-04-26 — Set 3 #3 reviewer suggestion; user-reframing recalibrated importance to secondary (less critical when default is "load more")

Description

The TL;DR (ACCORE-META-T-M5T8) lists the FIRST 2-3 docs to load. A ### Fast-path docs sub-section (or @fastpath tag) declaratively marks the docs covering the 80% case — distinct from "Először olvass" (which is conversational guidance) by being machine-friendly + parsable.

User's recalibration: with "load more upfront" preference (ACCORE-META-T-R2W6), agent will tend to load broader anyway → fast-path tagging becomes secondary, not critical. Still useful as a SIGNAL for which docs to start with when the agent does decide to be selective.

Fix direction

Add a small ### Fast-path docs section in topic READMEs listing 2-3 docs that suffice for 80% of agent queries. Example:

### Fast-path docs
- `BINARY_FORMAT.md` — wire format spec (most queries land here)
- `BINARY_OPTIONS.md` — configuration reference
- `BINARY_WRITERS.md` — IBufferWriter integration

docs-discovery/SKILL.md honours: when topic identified, fast-path docs load first; expanded set (full topic-pair + sister docs) on demand or per R2W6 preference.

Acceptance criteria

  • ACCORE topic READMEs have the block where applicable.
  • docs-discovery/SKILL.md parses and honours the fast-path.
  • Marker convention defined and consistent.
  • ACCORE-META-T-M5T8 (TL;DR — predecessor / parent convention)
  • Cross-source: Set 3 #3 (only 1 source mentioned this — weaker convergence than M5T8)

ACCORE-META-T-V7L2: ADR quality lint / structural validator

Priority: P3 · Type: Skill enhancement · Status: Open · Area: adr-author/SKILL.md Step 8 extension (or new Step 10) + optional references/ADR_LINT.md Origin: 2026-04-26 — Set 1 #7 + 2-of-3 Copilot reviewer agreement (one explicit suggestion: warning, not hard-fail)

Description

adr-author/SKILL.md Steps 5-8 produce ADRs but don't VALIDATE them post-write. A lint pass would catch:

  • Missing required sections (## Status, ## Context, ## Decision, ## Consequences, ## Alternatives considered, ## Related)
  • Status field format: Proposed (YYYY-MM-DD) | Accepted (...) | Superseded by ADR-XXXX | Rejected (...)
  • Alternatives section: ≥ 2 alternatives present (or explicit "no alternatives — implementation path" justification)
  • Decision section: explicit decision criterion, not just "we'll do X" without why
  • Cross-ref consistency: Supersedes / Superseded by / Related ADRs IDs valid (file exists, anchor exists)

Fix direction

Add Step 10 to adr-author/SKILL.md (or extend Step 8): after Write, run lint over the generated ADR. Surface any FAIL as polite suggestion (warning mode, not blocker — per Copilot reviewer #2).

Could alternatively be a protocol-audit invariant D2 (docs-link integrity) extended to validate ADR structure — synergy with ACCORE-META-T-K2P7 (path/anchor mismatch detection).

Acceptance criteria

  • Generated ADRs pass lint by construction (if user fills in placeholders correctly).
  • Lint reports are constructive (suggested fix, not just "FAIL").
  • Doesn't block ADR creation — quality nudge, not gate.
  • adr-author/SKILL.md Steps 5-8 (existing structure)
  • ACCORE-META-T-K2P7 (parallel "anchor mismatch" lint family — synergy candidate)
  • Cross-source: Set 1 #7 + Copilot reviewer #2 ("warning, not hard fail")

ACCORE-META-T-N8K3: Last verified against commit opt-in metadata field

Priority: P3 · Type: Convention (opt-in metadata) · Status: Open · Area: Long-form docs/ files (opt-in only) Origin: 2026-04-26 — Set 2 #3 + user anti-hallucination framing (drift detection prevents stale-context hallucination loops)

Description

Drift between .md docs and source code is a real hallucination cause: agent reads a doc, trusts it, the doc was written 6 months ago against an old API → wrong answer. A simple <!-- last-verified: <commit-hash> @ <YYYY-MM-DD> --> HTML-comment metadata field would let the agent know:

  • "This doc was verified against commit cdd54d3 (2026-04-05) — current HEAD is later — possibly stale, double-check the relevant .cs file."
  • vs. "Verified yesterday — trust it."

User's recalibration: anti-hallucination angle strengthens this entry's importance vs. the original "marginal utility" framing. Drift-detection IS hallucination prevention.

Fix direction

Opt-in only — not all docs need this. Suggested for:

  • Long-form architecture docs (ARCHITECTURE.md, BINARY/README.md, etc. — less frequent churn)
  • Reference docs (CONVENTIONS.md, GLOSSARY.md)
  • Stable API docs / wire-format docs

NOT for:

  • TODO / ISSUES files (high churn — verification not meaningful)
  • Decision Log / ADRs (immutable per LLMP-DEC governance)

Format: HTML-comment line at top: <!-- last-verified: <commit-hash> @ <YYYY-MM-DD> -->. Manual update by author on doc-modifying response. docs-check skill flags "doc with last-verified tag, age > N days, code path touched since" as a soft warning.

Acceptance criteria

  • Convention documented in CONVENTIONS.md or META_ISSUES.md reference section.
  • Opt-in — never required, never auto-fail.
  • docs-check skill respects the marker if present.
  • Anti-hallucination value: agent expresses "stale, verifying" instead of guessing.
  • Set 2 #3 (Copilot suggestion)
  • ACCORE-META-T-R2W6 (anti-hallucination framing motivates this)

ACCORE-META-T-P9F4: Pre-load expansion with foundational reference docs

Priority: P2 · Type: Protocol change (Session Setup section + Rule #1) · Status: Open · Area: copilot-instructions.md Session Setup + docs-discovery/SKILL.md Origin: 2026-04-26 — User reframing (correctness > token-economy); current 3-file pre-load may be too narrow

Description

Current session-start pre-load is 3 files (per LLMP-DEC-43): the active repo's copilot-instructions.md + 2 reactive skill SKILL.md (docs-discovery, docs-check). The 3 user-gated skills lazy-load on demand.

User feedback: this is too narrow. Foundational reference docs (ARCHITECTURE.md, GLOSSARY.md, CONVENTIONS.md, top-level project README.md) get queried in nearly every session. Lazy-loading them per-turn means each topic-specific question pays the load cost separately. Pre-loading at session-start amortizes once across the entire session.

User cost function (explicit): 5-8K extra session-start tokens are CHEAPER than 1 hallucination loop caused by missing foundational context.

Fix direction

Expand session-start pre-load to include foundational reference docs from active repo's docs/ root (when they exist):

  1. Active repo's copilot-instructions.md (current — keeps Rule #1 baseline)
  2. docs-discovery/SKILL.md (current — reactive)
  3. docs-check/SKILL.md (current — reactive)
  4. Active repo's root README.md (NEW)
  5. docs/ARCHITECTURE.md (NEW, if exists)
  6. docs/CONVENTIONS.md (NEW, if exists)
  7. docs/GLOSSARY.md (NEW, if exists — workspace-glossary)

Result: 4-7 files at session start (depending on which exist in the active repo). LOADED_DOCS prefix shows accurate count. ## Session Setup section in copilot-instructions.md updated.

For inherit files: pre-load also AyCode.Core's foundational docs (since this repo doesn't host them) — adjust the count similarly.

Acceptance criteria

  • Session-start LOADED_DOCS count: 4-7 files (was 3).
  • Foundational docs available without explicit user query → reduces "had to grep for context" loops.
  • docs-check's base context broader → more accurate drift detection.
  • Skill descriptions and Session Setup section in copilot-instructions.md updated.
  • LLMP-DEC entry recording the change (refines LLMP-DEC-43).
  • LLMP-DEC-43 (current 5-skill matrix with 2 reactive pre-loaded)
  • ACCORE-META-T-R2W6 (user-preference statement — same anti-hallucination motivation)
  • LLMP-DEC-58 / 60 (Framework-First retightening — pre-load expansion respects this: only same-or-lower-layer docs)

ACCORE-META-T-R2W6: Workspace user-preference statement (correctness > token-economy)

Priority: P2 · Type: Protocol change (new sub-rule or ## Workspace Load-Policy Preference section) · Status: Open · Area: copilot-instructions.md Origin: 2026-04-26 — User reframing of cost function: "felesleges kör költsége >> tokenköltség. inkább több, mint hibás."

Description

The current AI AGENT CORE PROTOCOL implicitly assumes "minimize tokens" as a calibration goal. User's actual cost function is different:

"Felesleges kör költsége >> tokenköltség. Inkább több, mint hibás."

Agent should prefer reading docs over guessing when uncertain. The amortization principle (LLMP-DEC-43 era) partially codifies this for session-start; doesn't extend explicitly to per-turn decisions.

Without an explicit preference statement, agents calibrate toward "minimum loading" defaults observed in their training. The workspace's actual preference is opposite: load broader, ask when unsure, never guess critical context.

Fix direction

Add a new section / Rule sub-bullet to copilot-instructions.md (location TBD: Rule #2 extension, new Rule #7, or a ## Workspace Load-Policy Preference section between ## Session Setup and the Rules). Suggested text:

**WORKSPACE LOAD-POLICY PREFERENCE:** This workspace prioritizes correctness
over token-economy. When uncertain whether you have current/sufficient
context on a topic, READ the relevant `.md` file first — do NOT guess from
memory or attempt to infer purely from code-search. Loading 5-10K extra
tokens upfront is cheaper than a wrong answer that requires user correction
+ retry. The amortization principle extends to ALL turns, not just session
start: every turn has the choice between (a) read-then-answer and (b)
guess-then-maybe-be-wrong; default to (a).

This explicit preference shifts agent calibration toward "load when uncertain".
It does NOT mean "load everything" — relevance still matters (Rule #2's docs-
before-code stays). It means "within the relevance scope, prefer broader
loading over narrower".

Acceptance criteria

  • Rule text in AyCode.Core canonical copilot-instructions.md (inherited by reference for non-Core primary files, or duplicated to all 5 — TBD per protocol-audit invariant style).
  • docs-discovery/SKILL.md and docs-check/SKILL.md reference this preference where it affects skill behaviour (cap revisit per ACCORE-META-T-C5J7).
  • LLMP-DEC entry recording the codification.
  • ACCORE-META-T-P9F4 (pre-load expansion — direct application)
  • ACCORE-META-T-C5J7 (cap revision — also direct application)
  • LLMP-DEC-43 (amortization principle — this preference extends it)
  • ACCORE-META-T-N8K3 (drift-detection — anti-hallucination companion)

ACCORE-META-T-C5J7: docs-check and docs-discovery cap revision (revisit fixed limits)

Priority: P3 · Type: Skill behaviour tuning · Status: Open · Area: docs-check/SKILL.md (volume cap), docs-discovery/SKILL.md (per-topic limit) Origin: 2026-04-26 — User reframing; LLMP-DEC-27 (volume cap = 3) calibration revisit

Description

docs-check/SKILL.md has a "max 3 items per response" volume cap (per LLMP-DEC-27, originally calibrated for "noise-aversion / silence beats noise"). docs-discovery/SKILL.md has per-topic file limits implicit in glob patterns.

User's recalibration: the noise-averse 3-cap may be too conservative under the "correctness > token-economy" preference (ACCORE-META-T-R2W6). Options:

  1. Higher fixed default (e.g., 5 or 7) — simple, predictable.
  2. Confidence-based (no cap if all proposals are high-confidence with quotable evidence; cap kicks in only when speculation creeps in) — better quality control but harder to calibrate.
  3. Configurable per session via a marker — flexible but adds state.

NOT dynamic complexity-based tuning (rejected per Set 1 #1 skip rationale — inconsistent across agents).

Fix direction

Two-step exploration:

  1. Update docs-check/SKILL.md volume cap: try max 5 instead of max 3. Observe over a few sessions: is signal/noise ratio better, worse, same?
  2. If "better" → codify as new default with LLMP-DEC entry refining LLMP-DEC-27. If "worse" → revert and consider confidence-based alternative.

For docs-discovery/SKILL.md: revisit per-topic file limit. Currently glob loads paired main+ISSUES+TODO. Consider expanding to load related sub-topic docs by default if they exist (e.g., LOGGING/README.md triggers also loads LOGGING_SERVER.md if present).

Acceptance criteria

  • Cap is documented numerically (no vague "as many as needed").
  • docs-check skill respects new cap.
  • LLMP-DEC entry recording the cap change (refines LLMP-DEC-27).
  • A short session-log validates the new cap doesn't introduce noise (signal/noise ≥ pre-change).
  • LLMP-DEC-27 (original 3-cap rationale — "silence beats noise")
  • ACCORE-META-T-R2W6 (preference shift — motivates this)
  • ACCORE-META-T-P9F4 (pre-load expansion — parallel "load more" direction)

TODO entry template

## ACCORE-META-T-XXXX: Short title

**Priority:** P0 / P1 / P2 / P3 · **Type:** Skill enhancement / Convention update / Registry change / Docs / Cleanup · **Status:** Open / InProgress / Closed (YYYY-MM-DD) · **Area:** <skill or registry name>
**Origin:** <where the need was observed — Phase X / specific incident / LLMP-DEC-N>

### Description
What needs to be done and why, with quotable evidence (file paths, behaviour observation, etc.).

### Fix direction
Proposed approach.

### Acceptance criteria
- Concrete observable outcomes.

### Related
- Sibling: `META_ISSUES.md#accore-meta-i-xxxx` (if a known issue spawned this TODO)
- LLMP-DEC: `LLMP-DEC-N` (if a decision motivated this work)