Ongoing-Projects Workflow + Dept-Based Routing

Closes the ongoing-projects-dev task. Established the ongoing-project model in practice, stood up the first Core department (IT), retired the conflicting single-_WorkingOn rule, and fixed the SMTM skills to support dept-routed tasks. Companion log: Core/AI/Logs/2026-06-25_AI-Config-Consolidation.md.

The model (now canonical, to be formalized by SMTM v5.2)

A third SMTM entity alongside Task (finite, closes) and Project (finite, has an end):

Ongoing Project = evergreen / no end. Lives at its primary work surface (a repo, or a KB-native dept folder) and gets one KB portal note. Work happens as ordinary SMTM tasks in the owning dept’s Tasks/; the task closes, the project lives on. ROADMAP.md/UPGRADES.md live once, at the primary surface. Logs → <dept>/Logs/. Never in _WorkingOn/Projects/.

Department-based structure (each active Core dept owns its scope end-to-end):

Core/<Dept>/
  JOB_DESCRIPTION.md     ← charter (scope, decisions, autonomy, owned projects)
  Tasks/                 ← dept-routed SMTM task files
  Logs/                  ← dated dev/ops logs
  <Project>/<Project>.md ← portal note per repo ongoing-project owned

Cross-dept / vault-level tasks stay in Core/_WorkingOn/Tasks/. ONE master tracker: Core/_WorkingOn/Tasks/_active.md, grouped by dept.

Decisions (CEO)

AI stays a top-level dept, peer to IT — not a sub-domain of IT. In this operating model AI agents are the workforce running every dept (a cross-cutting / Chief-of-Staff function), not a service IT maintains. The technology-maintenance slice already nests under AI as Core/AI/Tools/.
Per-dept Tasks/ + Logs/ adopted; the “single Core/_WorkingOn, no per-dept folders” rule retired.
Routing test: business-specific → <Biz>/<Dept>/Tasks/; cross-business system work with a clear Core dept → Core/<Dept>/Tasks/; vault-level/multi-dept → Core/_WorkingOn/Tasks/.

What changed

Core/IT dept stood up (P1):

Core/IT/JOB_DESCRIPTION.md created — owns monorepo, web-deploy, my_backup; A1 autonomy.
Core/IT/Tasks/ created; monorepo-cleanup-upgrade.md moved in + frontmatter fixed (was title: Tasks-Template, status: complete).
Core/IT/Monorepo/Monorepo.md portal created, bidirectional with repo AGENTS.md.
Registry Core/Processes/KB-OS/Ongoing-Projects.md — monorepo portal link filled.
Stale SSOT pointer fixed in ~/projects/monorepo/AGENTS.md (was MBR_WorkingOn\Projects\…).

Rule + skills cleanup (P4):

Retired the single-_WorkingOn rule → dept-routing rule, in both ai-config source and deployed ~/.claude/CLAUDE.md (kept in parity).
Removed the stale “Phase 7 not complete / don’t write to Core/_WorkingOn/Tasks” line (verified /mnt/d/FSS/KB/Business/ is gone).
Fixed 4 SMTM skills (task-start, task-continue, task-complete, task-prep) to search Core/*/Tasks/ dept folders — they previously resolved only _WorkingOn/Tasks/ and would have failed to launch dept-routed tasks. Tested: SMTM-v5.2→Processes/Tasks, monorepo-cleanup→IT/Tasks all resolve. Synced task-continue in ai-config source (was a pre-restructure Business/ path).

Consolidation (see companion AI log): purged 3 superseded plans (two Feb AI-config plans — config-ai repo + all gap-fixes built; the 2026-04-12 SMTM plan — shipped in v5.0/5.1). Added Priority-#2 note + component-table idea to ai-config ROADMAP/UPGRADES.

Reconciliation (avoided duplicate work)

The ongoing-project construct + dept-routing were already approved in KB-OS-Architecture.md (Rounds 2–3) and chartered as:

P3 = Core/Processes/Tasks/SMTM-v5.2-Ongoing-Projects.md (status: ready) — folds the model into SMTM_System.md.
ai-config work = Core/_WorkingOn/Projects/ai-config-rules-upgrade/ (4 phases).

This task became the execution/cleanup track (built IT, fixed skills, consolidated). P2 (monorepo-cleanup-upgrade) and P3 are independent and may run in parallel (different files/depts) — feed any P2-surfaced structural flaw into P3 before its version bump.

Open items (handed off, not blockers)

Source ↔ deployed CLAUDE.md drift — patched 2 specific items by hand; full reconciliation is ai-config-rules-upgrade Phase 2. Do not run deploy.sh until then.
3 of 4 SMTM skills unversioned (task-start/task-complete/task-prep live only in ~/.claude/commands/, not ai-config source) — import them. → AI dept.
Defense-in-depth reliability standard (from MBR/.../myMBR-OS/STANDARDS.md) approved for promotion to a Core IT standard — captured in Core/IT/JOB_DESCRIPTION.md UPGRADES.
Stale 3-layer task system (_Now.md/TASKS.md/_Next.md) buried in Core/AI/AI-Dev-Workflow.md — excise in an AI-dept pass.

Lessons (candidates — for approval before promoting)

Before drafting a plan, grep Tasks/ + Projects/ for existing chartered threads on the topic. This task nearly re-designed SMTM-v5.2 + ai-config-rules-upgrade, which already existed. [→ global CLAUDE.md / SMTM]
When changing folder topology, audit skills for resolution logic, not just literal stale paths. The SMTM skills had no stale path — they had a hardcoded folder assumption (_WorkingOn/Tasks/ only) that silently broke dept routing. Extends the existing stale-path-audit rule. [→ global CLAUDE.md]