Adam
/
AyCode.Core
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
AyCode.Core/.github/META_TODO.md

6.6 KiB
Raw Blame History

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)