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
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
my_OpenClaw	IT	repo	`~/utils/ai/my_OpenClaw/`	my_OpenClaw
rate-scanner	MBR (IT)	repo	`~/projects/mbr/rate-scanner/`	rate-scanner

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. Only KB-OS, as the sole KB-native project (a full folder, not a single note), uses DASHBOARD.md as its 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).

Standard structure

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.