141 lines
6.6 KiB
Markdown
141 lines
6.6 KiB
Markdown
# 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)
|
|
```
|