chore(audit): L4.3 module manifests audit — count v1→v2 gap #60

New issue

Closed

opened 2026-05-05 01:01:16 +02:00 by pdurlej · 1 comment

pdurlej commented

2026-05-05 01:01:16 +02:00

Owner

Spec sources (whitelist)

modules/*/module.yaml — all 81 module manifests
schema/module.schema.json — v1 schema
schema/module.schema.v2.json — v2 schema (ADHD counter extensions: predecessor, alternatives, todo_cap, drift_audit)
PLATFORM_CHARTER.md §3 (review-by-impact size classes)
Issue #59 (meta-issue, for context only)

Extracted context

From Issue #59 §"Why this layer matters":

Until L4 is audited and decomposed, Phase 03 (control plane: platformctl) cannot start cleanly —
Phase 03 depends on L4.6 (platformctl skeleton) being complete and L4.3 (module manifests) being
at least 30 modules in v2.

From state/reports/STATE_OF_PLATFORM_2026-05-03.md (referenced in issue #59):
6/85 modules in v2, plus 3 awaiting Codex wave 3 merge

Audit result (glm, 2026-05-05): 0/81 modules contain schema_version or predecessor fields.
All manifests are v1-only. The "6 in v2" claim from the May 3 report cannot be confirmed in
the current working tree — either they were reverted, or the report counted partial fields.

Do NOT read (unless escape hatch fires)

control-plane/platformctl/tools/ — not relevant to manifest content audit
prompts/ — orthogonal to module schema versioning
baseline/ — immutable, not part of this audit

Allowed touched paths

(none — this is audit-only, outputs are a comment on this issue and on #59)

Why this exists (product-first)

Without knowing which modules are v2-complete vs v1-only, no agent can safely start Phase 03 work. The plan says "30 modules in v2" is the gate. We need a concrete list.

Why this matters now

Phase 03 is blocked. Issue #57 (Antigravity setup) is blocked. All swarm work downstream of L4.3 is blocked.

What "done" looks like

Comment on this issue listing all 81 modules with their current schema version (v1 / partial-v2 / v2)
For each v2 field (predecessor, alternatives, todo_cap, drift_audit), count how many modules have it populated
Identify the gap: how many modules need v2 upgrade to reach the 30-module threshold
Output is a structured list — NOT manifest changes

Scope

In scope:

Read and classify all 81 module.yaml files
Produce gap analysis

Out of scope:

Actually writing v2 fields into manifests (separate follow-up issues)
Changing schemas
Modifying platformctl

Suggested approach

grep -c each v2-only field across all module.yaml files
For each module, check if schema_version: v2 exists or if any v2-only field is present
Classify: v1-only / partial-v2 / full-v2
Summarize counts and list v2-complete modules by name

Escape hatch

If during audit you find that module.yaml files reference a different schema than module.schema.json or module.schema.v2.json, STOP and comment — schema drift is a process issue.

Unknowns / owner questions

The May 3 report claimed "6/85 in v2" but audit finds 0 — were these reverted? Does operator know?

Risk class

risk/process — incorrect count blocks Phase 03 gate decision

Trace

Original source: Issue #59 §"Suggested atomic issues" item 1
Migrated by: glm (decomposing agent), 2026-05-05
Related issues: #59 (parent meta-issue)

## Spec sources (whitelist) - `modules/*/module.yaml` — all 81 module manifests - `schema/module.schema.json` — v1 schema - `schema/module.schema.v2.json` — v2 schema (ADHD counter extensions: predecessor, alternatives, todo_cap, drift_audit) - `PLATFORM_CHARTER.md` §3 (review-by-impact size classes) - Issue #59 (meta-issue, for context only) ## Extracted context > From Issue #59 §"Why this layer matters": > ``` > Until L4 is audited and decomposed, Phase 03 (control plane: platformctl) cannot start cleanly — > Phase 03 depends on L4.6 (platformctl skeleton) being complete and L4.3 (module manifests) being > at least 30 modules in v2. > ``` > From `state/reports/STATE_OF_PLATFORM_2026-05-03.md` (referenced in issue #59): > ``` > 6/85 modules in v2, plus 3 awaiting Codex wave 3 merge > ``` > Audit result (glm, 2026-05-05): **0/81 modules contain `schema_version` or `predecessor` fields.** > All manifests are v1-only. The "6 in v2" claim from the May 3 report cannot be confirmed in > the current working tree — either they were reverted, or the report counted partial fields. ## Do NOT read (unless escape hatch fires) - `control-plane/platformctl/tools/` — not relevant to manifest content audit - `prompts/` — orthogonal to module schema versioning - `baseline/` — immutable, not part of this audit ## Allowed touched paths - (none — this is audit-only, outputs are a comment on this issue and on #59) ## Why this exists (product-first) Without knowing which modules are v2-complete vs v1-only, no agent can safely start Phase 03 work. The plan says "30 modules in v2" is the gate. We need a concrete list. ## Why this matters now Phase 03 is blocked. Issue #57 (Antigravity setup) is blocked. All swarm work downstream of L4.3 is blocked. ## What "done" looks like - [ ] Comment on this issue listing all 81 modules with their current schema version (v1 / partial-v2 / v2) - [ ] For each v2 field (predecessor, alternatives, todo_cap, drift_audit), count how many modules have it populated - [ ] Identify the gap: how many modules need v2 upgrade to reach the 30-module threshold - [ ] Output is a structured list — NOT manifest changes ## Scope **In scope:** - Read and classify all 81 module.yaml files - Produce gap analysis **Out of scope:** - Actually writing v2 fields into manifests (separate follow-up issues) - Changing schemas - Modifying platformctl ## Suggested approach 1. `grep -c` each v2-only field across all module.yaml files 2. For each module, check if `schema_version: v2` exists or if any v2-only field is present 3. Classify: v1-only / partial-v2 / full-v2 4. Summarize counts and list v2-complete modules by name ## Escape hatch If during audit you find that module.yaml files reference a different schema than `module.schema.json` or `module.schema.v2.json`, STOP and comment — schema drift is a process issue. ## Unknowns / owner questions - The May 3 report claimed "6/85 in v2" but audit finds 0 — were these reverted? Does operator know? ## Risk class - [x] `risk/process` — incorrect count blocks Phase 03 gate decision ## Trace - Original source: Issue #59 §"Suggested atomic issues" item 1 - Migrated by: glm (decomposing agent), 2026-05-05 - Related issues: #59 (parent meta-issue)

pdurlej added the

proposed

label

2026-05-05 01:01:16 +02:00

pdurlej commented

2026-05-05 01:01:47 +02:00

Author

Owner

⚠️ CLOSED — this issue was created with wrong identity (pdurlej/admin via MCP). Recreating as glm identity.

pdurlej closed this issue

2026-05-05 01:01:47 +02:00