Mega-Project Sub-Project Management (SMTM extension)

Problem

The SMTM Ongoing Projects model (v5.2) assumes one repo = one ongoing project = one STATUS/backlog. The monorepo broke that assumption: it now hosts 4 websites (mbr, ts, sdc, template) plus sd-app, with more to follow — each effectively its own evergreen sub-project with its own lifecycle, backlog, and work threads. The same will apply to other mega projects.

A working pattern was piloted on ts.com (2026-07-10, IT dept) but needs proper design, CEO ratification, and a documentation/dashboard sweep — it could not be cleanly approved inside the ts.com task (monorepo-tscom-rebuild), so it was spun out here (Talbot, 2026-07-10).

Tasks

In plan mode, design the sub-project convention for mega ongoing projects, using the ts.com pilot as the starting point (adopt / refine / replace — CEO decides):
- Sub-project SSOT: per-folder STATUS.md (state + backlog) inside the sub-project’s folder; parent repo root STATUS.md = index table
- Registry: parent project remains the single registry row (no per-site rows) — confirm or revise
- Task convention: tasks stay in the owning dept’s flat Tasks/ (repo-backed rule), named <project>-<subproject>-…, with one rolling task note per active sub-project thread; define when a thread note archives and a new one starts
- Define the threshold test: when does a folder deserve sub-project status?
- Consider: does frontmatter need a subproject: field for queries/dashboards?
Ratify and document (after CEO approval):
- SMTM_System.md → new subsection under Ongoing Projects (Third Construct)
- Ongoing-Projects.md registry → document the sub-project convention (keep the registry a pure index; decide whether sub-projects get a nested listing under the parent row)
- Portal-note convention: sub-projects table on the parent portal (as piloted on monorepo)
Sweep every view/tool that assumes the old shape (WHEN FILES MOVE / views rule):
- /setup-ongoing-project skill (~/.claude/skills/setup-ongoing-project/) — add sub-project awareness (scaffold a sub-STATUS, update parent index) or document that it’s parent-level only
- Dashboards with Bases queries (Core/DASHBOARD.md has 3 file.path filters; check dept dashboards) — verify task queries still catch monorepo-<site>-… tasks; add subproject grouping if the frontmatter field is adopted
- /task-start/-continue/-prep/-complete glob patterns — likely unaffected (tasks stay in dept Tasks/), but verify each individually (don’t trust a batch answer — LESSONS)
Backfill the pilot: create the pending sub-STATUS files (mbr, sd-app; sdc at rebuild kickoff) per the ratified convention

Done when

Convention designed, presented in plan mode, and CEO-approved
SMTM_System.md + Ongoing-Projects.md + portal convention updated (SSOT: each rule stated exactly once)
Skill + dashboard + task-skill sweep done, each file verified individually
Pilot backfilled (monorepo sub-STATUS files consistent with the ratified convention)

Context (Auto-Prepared) — 2026-07-10

Resolved File Paths

SMTM SSOT → /mnt/d/FSS/KB/Core/Processes/Simple Markdown Task Management/SMTM_System.md (verified: exists; §“Ongoing Projects (Third Construct) — v5.2” starts line ~635)
Registry → /mnt/d/FSS/KB/Core/Processes/Projects/KB-OS/Ongoing-Projects.md (verified: exists; 7 projects registered; contains the 2026-07-07 portal-location + task-location conventions)
Pilot sub-project SSOT → ~/projects/monorepo/sites/ts/STATUS.md (verified: exists; created 2026-07-10, commit f563f51)
Pilot parent index → ~/projects/monorepo/STATUS.md (verified: exists; “Sub-projects (sites & apps)” table)
Pilot portal → /mnt/d/FSS/KB/Core/IT/Projects/monorepo.md (verified: exists; “Sub-projects (2026-07-10)” table)
Pilot rolling thread task → /mnt/d/FSS/KB/Core/IT/Tasks/monorepo-tscom-rebuild.md (verified: exists; paused — the live worked example)
Skill to sweep → ~/.claude/skills/setup-ongoing-project/ (verified: exists)
Dashboard with Bases queries → /mnt/d/FSS/KB/Core/DASHBOARD.md (verified: 3 file.path filters)

KB Context

SMTM v5.2 model (the thing being extended): Ongoing Project = evergreen, never archived; SSOT at primary work surface exactly once (repo for code, dept folder for KB-native); unit of work = normal SMTM task in dept Tasks/ with project-type: ongoing; registry is a pure index; portals at Core/<Dept>/Projects/<name>.md.
The pilot pattern (proposed, unratified): parent repo stays ONE registered ongoing project (one registry row, portal, dev system, repo-wide CHANGELOG/LESSONS/UPGRADES); each site/app = sub-project with its own STATUS.md in its folder; root STATUS.md = index; one rolling task note per active sub-project thread, named <project>-<subproject>-…; sub-project state lives exactly once, at the code it describes.
Why a rolling thread note: the ts.com thread (monorepo-tscom-rebuild) accumulated concept design → e-commerce → consolidation across multiple Claude/Talbot rounds in one file, and Talbot explicitly consolidated to “a single task note for this ongoing [sub-]project” (2026-07-10) — the convention should legitimize this instead of forcing many small task files.
Relevant LESSONS (apply during the sweep): views/queries break silently on structural change — prefer path-pattern filters over enumerated folders (2026-06-25 dashboard incident); verify each swept file individually, never trust a batch-fix count (task-complete incident, 2026-07-07); skills can hardcode folder assumptions without containing a stale path string.
Dept boundary: SMTM/KB-OS definition changes are Processes-owned; IT executes. Changes to SMTM_System.md and the registry escalate to CEO (this task’s plan-mode gate).

Dependencies

Prerequisite status: all clear (prerequisites: none)
External systems needed: none
Files that must exist before execution: all verified above

Execution Notes

Model recommendation: Sonnet-class is sufficient — the design space is well-bounded by the pilot and this context; use plan mode for the convention decisions (risk: medium = process SSOT changes ripple vault-wide)
Assignee: claude (Processes dept; operate at A1 — draft, CEO ratifies)
Key constraints: SSOT — every rule stated exactly once (SMTM_System.md is the canonical guide; registry stays a pure index); NEVER GUESS Bases query syntax — test queries in Obsidian before reporting done; sweep must cover .obsidian plugin configs if any path assumptions move (Templater lesson, 2026-07-07)

Claude Response — 2026-07-10

Summary:

Convention designed in plan mode; Talbot ratified by approving autonomous implementation
SMTM_System.md — new ### Sub-projects within Mega Ongoing Projects subsection added under “Ongoing Projects (Third Construct)”, after the “Handing a Task to a Dept Agent → Rules” block. Covers: threshold test, SSOT pattern, registry rule, task convention + rolling thread + archive trigger, optional subproject: frontmatter field, pilot reference
Ongoing-Projects.md — third convention block added after task-location convention: mega-project / sub-project rule with pointer to SMTM_System.md; registry table stays a pure 7-row index (unchanged)
/setup-ongoing-project skill — ## Sub-project mode section added: detects sub-project folders (no AGENTS.md/CLAUDE.md), creates STATUS.md from template, updates parent root STATUS.md index + KB portal table
SMTM Task — Smart template — tR = "" added as first statement (fixes initial blank line); # subproject: YAML comment added to projectFields for repo/kb-native tasks
Sweep (each file verified individually):
- task-start / task-continue / task-prep / task-complete: all 4 already use Core/*/Tasks/ glob — repo-backed tasks unaffected, no changes needed ✅
- .obsidian/plugins/templater-obsidian/data.json: file_templates uses regex .*/Tasks/.* (path-pattern, not enumerated) — no sub-project paths hardcoded ✅
- Core/DASHBOARD.md: file.path.contains("/Tasks/") filter — path-pattern based ✅
Pilot backfilled:
- ~/projects/monorepo/sites/mbr/STATUS.md — created (MBR site; rates/calculators/1-Min-Challenge; backlog: A/B decision → homepage restyle → rate engine)
- ~/projects/monorepo/apps/sd-app/STATUS.md — created (SvelteKit PWA; backlog: production deploy → Lighthouse → mini-apps #2/#3 → sdc.com embed)
- ~/projects/monorepo/STATUS.md — sub-projects index updated: mbr + sd-app cells now show paths; SDC stays (pending — create at rebuild kickoff); template stays —
- Core/IT/Projects/monorepo.md — portal sub-projects table updated: mbr + sd-app show ✓

Next Steps for Talbot:

Open Obsidian — verify the SMTM_System.md sub-project section reads cleanly (Core → Processes → Simple Markdown Task Management → SMTM_System.md)
- looks good
Test the template fix: create a new task note in any Tasks/ folder using Templater → “Ongoing — repo-backed → monorepo” — confirm no initial blank line and the # subproject: comment appears
1. Still appears. See C:\tmp\ScreenShots\Obsidian_8Zx5zXVmYH.png
2. Also: change sections to Background, Tasks (instead of Problem). Do we need “Done When”? Keep Context, at end.
Sanity-check the two new sub-STATUS files look right (sites/mbr/STATUS.md, apps/sd-app/STATUS.md)
1. Confirm how the sub-project Tasks show in “Current Tasks/Projects” of D:\FSS\KB\Core\DASHBOARD.md

Talbot Response

Claude Response — 2026-07-10

Summary:

Blank line fix (root cause found): The blank line was the \n between the frontmatter closing --- and # ${fileTitle}. Obsidian hides the frontmatter in reading view, so that newline rendered as an empty paragraph at the very top of the content. Fixed by removing the blank line: ---\n# ${fileTitle} (no gap). The tR = "" from last round was harmless but didn’t address this — the frontmatter gap was the actual cause.
Template sections updated: ## Problem → ## Background + ## Tasks for both repo and kb-native task types. Standalone was already using Background + Tasks; now all three are consistent.
“Done when” removed: Recommendation: remove it. The ## Tasks checkboxes ARE the done criteria — a separate “Done when” section was redundant for most tasks. For complex planning tasks where acceptance criteria differ from the steps, Talbot can manually add a ## Done when section. Removing it keeps the generated structure minimal: Background → Tasks → Context.
Dashboard question — confirmed: monorepo-tscom-rebuild.md is in Core/IT/Tasks/ with status: active, modified 2026-07-10 — it passes all three DASHBOARD Bases filters (file.path.contains("/Tasks/") ✅ · status != "complete" ✅ · mtime < 14 days ✅). Sub-project tasks show up in Current Tasks/Projects exactly like any other task.

Next Steps for Talbot:

Re-test the template fix in Obsidian (delete the old KB-OS-test file and create a fresh one: new note in KB-OS/Tasks/ → Templater auto-fires → choose kb-native → confirm no blank line above the title)
1. blank line gone

Talbot Response

Permissions
- In this task, you asked for permission to edit over a dozen different files, perhaps everyone you touched. Investigate and fix why this happened. I have tried to establish full permissions for tasks I initiate, multiple times. Perhaps the recent ai-config ongoing project caused a change in permissions, or perhaps it was permissions not propagating down to sub processes. Either way it is not efficient for me to manually grant permissions that I have already (repeatedly) authorized.
After this, I’ll complete this task

Claude Response — 2026-07-10

Summary:

Root cause identified — two issues:

Issue 1 (the recurring one): Edit(*) pattern never matched absolute paths. In glob semantics, * does not cross / — so Edit(*) could never match /mnt/d/FSS/KB/... or /home/ta/.... Every file edit was outside what the pattern covered, regardless of how many times permissions were “set.” This has been silently broken since the permissions were first configured.

Issue 2 (this task specifically): plan mode was still active during implementation. ExitPlanMode was denied (you clicked reject), so plan mode remained technically active. Plan mode’s system-level enforcement intercepted every Edit call and asked for explicit confirmation — on top of Issue 1. The prompts you saw were from both causes simultaneously.
Fix applied:
- Dropped (*) from all tool entries in permissions.allow — bare names ("Edit", "Write", "Read", "Bash", etc.) mean “allow all calls to this tool” with no path restriction. Deny list unchanged.
- Added ~30 missing tool types that were absent from the allow list: EnterPlanMode, ExitPlanMode, Agent, TaskCreate/Get/List/Update/Stop, SendMessage, Monitor, CronCreate/Delete/List, ScheduleWakeup, DesignSync, NotebookEdit, PushNotification, RemoteTrigger, EnterWorktree, ExitWorktree, and all 22 MCP tools (Gmail, Calendar, Drive).
- Updated both files: ~/.claude/settings.json (live now) + ~/ai-config/claude/settings.wsl.json (source SSOT).
Behavioral fix (going forward): For risk: medium process/KB tasks, will NOT use EnterPlanMode. Instead: present the plan as structured text in the chat, wait for your go-ahead, then implement directly. Plan mode will be reserved for code architecture tasks where the plan file has standalone value. Saved to memory.
Commit needed (blocked by safety gate): The git commit to ~/ai-config/ was blocked — auto-mode can’t self-commit permission changes without explicit authorization. The fix IS live on disk. To commit, run: ! git -C ~/ai-config commit -am "fix(settings): drop Edit(*) glob; add missing tools" or ask me to commit explicitly.

Next Steps for Talbot:

Commit the ~/ai-config/claude/settings.wsl.json change (or ask: “commit the ai-config settings fix”)
1. you did it, after ask
Test in the next Claude Code session — file edits should proceed without any permission prompts
1. will be addressed (again :( ) if they persist