Ongoing Projects — Registry

The one place that answers: what ongoing (evergreen) projects exist, who owns them, and where do they live? Ongoing projects are NOT in _WorkingOn/Projects/ (that folder is finite-only). Each lives at its primary work surface — a repo or a KB dept folder. KB visibility is a single portal note, homed at Core/<Dept>/Projects/.

Project	Owner dept	Type	SSOT home	KB portal
KB-OS	Processes	KB-native	`Core/Processes/Projects/KB-OS/`	KB-OS
Ideas-Workflow	Processes	KB-native	`Core/Processes/Projects/Ideas-Workflow/`	Ideas-Workflow
Focus	Processes	KB-native	`Core/Processes/Projects/Focus/`	Focus
ai-config	AI	repo	`~/ai-config/`	ai-config
monorepo	IT	repo	`~/projects/monorepo/`	monorepo
web-deploy	IT	repo	`~/utils/web/web-deploy/`	web-deploy
my_backup	IT	repo	`/mnt/d/FSS/Software/Utils/PythonUtils/my_backup/`	my_backup
System-Maintenance	IT	KB-native	`Core/IT/Projects/System-Maintenance/`	System-Maintenance
my_OpenClaw	IT	repo	`~/utils/ai/my_OpenClaw/`	my_OpenClaw
rate-scanner	MBR (IT)	repo	`~/projects/mbr/rate-scanner/`	rate-scanner
CRM-20	IT	repo	`~/utils/crm-20/`	CRM-20
Strategies-Library	SDC (IP)	KB-native	`SDC/IP/Projects/Strategies-Library/`	Strategies-Library

Portal-location convention (2026-07-07): every Ongoing Project’s KB portal lives at Core/<Dept>/Projects/<name>.md (repo projects — flat note) or Core/<Dept>/Projects/<name>/ (KB-native — full folder, e.g. KB-OS). This gives Ongoing Projects the same folder-level symmetry as finite work (Tasks/ + Projects/ per dept), replacing the prior arrangement where portals were scattered across dept-specific locations (Core/IT/Monorepo/, Core/IT/Utils/Custom/, Core/AI/AI-config.md). Flat naming after the project/repo (ai-config.md, monorepo.md, web-deploy.md, my_backup.md, my_OpenClaw.md) means no DASHBOARD.md-collision problem to solve — each note is already uniquely named. KB-native projects (full folders, not single notes — KB-OS, Ideas-Workflow) use DASHBOARD.md as their folder-note portal. See Core/Processes/Logs/2026-07-07_Ongoing-Projects-Folder-Convention.md.

Task-location convention (2026-07-07): KB-native projects self-contain their tasks — Core/<Dept>/Projects/<name>/Tasks/ (e.g. Core/Processes/Projects/KB-OS/Tasks/) — since the project folder already holds the rest of the live state, and co-location gives a natural context walk-up (task → sibling STATUS/ROADMAP → dept). Repo-backed projects keep tasks in the flat dept-wide Core/<Dept>/Tasks/, since their real context hierarchy lives in the repo, not the KB portal note. See Core/Processes/Logs/2026-07-07_KB-Native-Task-Location-Split.md.

Mega-project / sub-project convention (2026-07-10): When an Ongoing Project hosts multiple independent sub-projects (each with its own backlog and deployment target), it stays as one registry row. Sub-projects live inside the parent’s repo folder — each qualifying folder gets a STATUS.md (state + backlog); the root STATUS.md is the index table. KB portal gets a “Sub-projects” table. Tasks stay in the dept’s flat Tasks/, named <project>-<subproject>-<descriptor>; one rolling thread note per active sub-project thread. See SMTM_System.md → Sub-projects within Mega Ongoing Projects for the full convention. Piloted on monorepo (ts.com, 2026-07-10).

Business strategy-doc convention (2026-07-15): each business’s <Biz>/Strategy/ follows the same thin-TOC/SSOT split as ongoing projects — ROADMAP.md is a thin table-of-contents that links down (no restated Mission/Vision/rocks — those live once, in their own SSOT files), Strategic Plan.md is the full strategy SSOT, Filter+Focus.md is the Biggest-Rocks list + decision log feeding the Plan’s Governance cadence, and <Biz>/DASHBOARD.md (the business root portal) links all three. No third “business plan” document — SSOT rule holds. Reference implementation: MBR/Strategy/ (ROADMAP.md refreshed, DASHBOARD.md wired, 2026-07-15). Applied to SDC/Strategy/ 2026-07-15 (ROADMAP.md created, DASHBOARD.md wired) despite no formal dept activation — content already existed, so building the thin index was low-cost; SDC has no Filter+Focus.md/90-day-rocks/Governance section yet (flagged as an open gap on its ROADMAP, not pre-built). FSS remains fully dormant (no Strategy/ folder at all) — still holding on that one until real content exists. See MBR/Strategy/Tasks/mBR-Business-Plan-SSOT-Structure.md for the worked decision.

Standard structure

All repo projects are local-only (2026-07-17): no usable remotes — git = on-machine history/rollback; off-site durability = my_backup (Kopia + B2). Monorepo’s stale GitHub origin (last push 2026-05-26) counts as local too. Never push / add remotes without Talbot’s explicit direction.

Repo projects (code lives in a git repo): AGENTS.md (SSOT context) + CLAUDE.md / GEMINI.md (thin wrappers) + README.md + STATUS.md (live state) + CHANGELOG.md + LESSONS.md + ROADMAP.md + UPGRADES.md. The KB gets one portal note that links bidirectionally with the repo README.md.

KB-native projects (no repo — the vault is the artifact, e.g. KB-OS): the dept folder holds STATUS.md + ROADMAP.md + UPGRADES.md + LESSONS.md; the folder note is the portal.

SSOT rule: ROADMAP.md and UPGRADES.md live at the primary work surface exactly once — in the repo for code projects, in the KB dept folder for KB-native projects. Never both. The portal note links to wherever they live.

Logs: the owning dept’s Logs/ folder.

A unit of work on an ongoing project = a normal SMTM task. KB-native projects: the task lives in Core/<Dept>/Projects/<name>/Tasks/ (self-contained, e.g. KB-OS). Repo-backed projects: the task lives in Core/<Dept>/Tasks/ and points at the repo/folder for context. Either way, the task closes; the ongoing project lives on.

Handing a Task to a Dept Agent

Full step-by-step workflow + worked example moved to the canonical guide: SMTM_System.md → Ongoing Projects (Third Construct) → “Handing a Task to a Dept Agent — The Realized Workflow”. This registry stays a pure index (what exists, who owns it, where it lives); process/workflow documentation lives in SMTM_System.md, the single authoritative guide.