Skip to content
FSS Knowledge Base

Ongoing-Project Task Location — KB-Native vs. Repo-Backed Split

Section titled “Ongoing-Project Task Location — KB-Native vs. Repo-Backed Split”

Date: 2026-07-07 Project/Task: ongoing-projects-clarifications (KB-OS ongoing project) Status: ✅ Complete

Summary

Section titled “Summary”

Talbot questioned the dept-flat task workflow while filing his first task against an ongoing project: shouldn’t a task related to an ongoing project live inside that project’s own folder rather than a separate dept Tasks/ folder? Self-containment would also give better context hierarchy — an agent working a KB-OS task could walk up to sibling KB-OS docs before falling back to the dept.

Resolved with a type-based split rather than a single new rule for all ongoing projects.

Decision

Section titled “Decision”
  • KB-native projects (the KB folder is the project — e.g. KB-OS) → tasks go in Core/<Dept>/Projects/<name>/Tasks/. Self-containment is a real win here: zero filename-collision risk, and it delivers the context walk-up Talbot wanted (task → sibling project docs → dept only if still short on context).
  • Repo-backed projects (monorepo, ai-config, web-deploy, my_backup — the KB portal is a one-file pointer at an external repo) → tasks stay dept-flat in Core/<Dept>/Tasks/. Their real context hierarchy already lives in the repo itself (AGENTS.md, package docs); nesting a Tasks/ folder under the thin KB portal would just build a second, thinner mirror of repo structure inside the KB — a step backward for SSOT, and it would reverse the flat-note portal decision made hours earlier the same day (Ongoing-Projects-Folder-Convention task).

Documented as the canonical convention in Core/Processes/Projects/KB-OS/Ongoing-Projects.md (“Task-location convention (2026-07-07)”) and in SMTM_System.md → “Handing a Task to a Dept Agent” (step 2 now branches on project type; added a KB-native worked example alongside the existing repo-backed monorepo one).

What changed

Section titled “What changed”
  • Created Core/Processes/Projects/KB-OS/Tasks/; moved KB-OS’s 3 active tasks into it (KB-OS-next-upgrades.md, KB-OS-portal-rename.md, ongoing-projects-clarifications.md), adding project: KB-OS / project-type: ongoing frontmatter to each.
  • KB-OS/DASHBOARD.md — core-docs table and “Working on it” section repointed at the new Tasks/ subfolder.
  • Tasks/_active.md — updated to the new locations for all 3 moved tasks.
  • Load-bearing skill fix: /task-start, /task-continue, /task-prep, and /task-complete (~/.claude/commands/*.md) all had their locate-glob extended from dept-flat-only (Core/*/Tasks/) to also match Core/*/Projects/*/Tasks/. Without this, none of the four skills could have found a task filed under the new KB-native convention. Verified each glob against the real filesystem before considering the fix done.
  • /task-complete needed extra work beyond the glob: it was more stale than the other three skills — it still said “AI Response / Human Response” instead of “Claude Response / Talbot Response,” and it filed closures into Tasks/_tmp.md instead of Tasks/_active.md. Brought in line with the other three.
  • Side fixes surfaced during the same investigation:
    • Deploy Online.md moved Core/Processes/Projects/KB-OS/ → Core/IT/Utils/Custom/Deploy Online.md (git mv, history preserved). Updated KB-OS/DASHBOARD.md, Core/Processes/JOB_DESCRIPTION.md (dropped the conflicting ownership claim), and Core/IT/JOB_DESCRIPTION.md (added it to IT’s Utils scope) to match.
    • KB-OS/Focus-Pages.md stub had its wikilink path-qualification backwards ([Core/IT/Utils/Custom/Focus-Pages](/core/it/utils/custom/focus-pages/) — links to the ambiguous bare name with the real path stuffed in the label). Fixed to [Focus-Pages](/core/it/utils/custom/focus-pages/).

Gotcha

Section titled “Gotcha”

task-complete had never actually received the dept-glob fix from the 2026-06-25 dept-routing change, despite the global AGENTS.md rule citing “4 SMTM skills… broke this way” as if all four had been addressed together. Worth remembering: after a batch-fix claim, verify each affected file individually rather than trusting the count — this one sat silently broken for 12 days.

Next Steps

Section titled “Next Steps”
  • Talbot to run /task-start against Core/Processes/Projects/KB-OS/Tasks/DASHBOARD-efficiency.md (already created) to confirm the full KB-native workflow end-to-end.