# 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.

### Related

- 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).

### Related

- LLMP-DEC-59 (typo fix during Phase 6 — discovery context)

---

## ACCORE-META-T-F8R3: `Current protocol state` summary auto-staleness detection

**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

### 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.

Manual refresh worked (LLMP-DEC-60), but a periodic/automated reminder would catch drift earlier.

### Fix direction

Two complementary options (pick one or combine):

**(a) `protocol-audit` invariant `M1`** (meta-summary integrity, optional):
- Parse `Current protocol state` section claims (date, file count, skill list, ID format).
- Compare against ground truth (filesystem walk, file content).
- Surface drift with suggested patch.

**(b) `docs-check` skill** flags the summary section as stale if N (e.g., N ≥ 3) new LLMP-DEC entries have been added since the summary's last refresh date.

### 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.

### Related

- LLMP-DEC-25 (summary section design)
- LLMP-DEC-60 (most recent manual refresh)
- LLMP-DEC-62 (this META-TODO's introduction)

---

## 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)
```