--- feature_id: FTR-38 title: Multi-Sub-Project Awareness category: Foundation optional: true depends_on: [FTR-07, FTR-08] source: Not from Project_Kickoff_Seed_Prompt_v2.3.md — supplied directly by the user, drafted from real production use in the S.D project (person-centered multi-project pattern: one root folder for one client, containing several genuinely separate projects, each self-contained, sharing a root-level drop folder, trackers, and admin layer). No corresponding item in Bootstrap_Function_Registry.md. See coverage_report.md Section 10. registry_refs: [] --- # Multi-Sub-Project Awareness Depends on: [FTR-07 — Folder Structure](../items/folder-structure.md), [FTR-08 — File Naming, Track IDs & Versioning](../items/file-naming-and-versioning.md) ## What this is Defines how the agent operates when a single Claude project root actually contains multiple genuinely separate sub-projects under one umbrella — as opposed to one project with internal tracks, or several unrelated Claude projects that happen to share a client. This is a base capability: it says nothing about what any particular sub-project is for, and it does not replace or duplicate FTR-07 or FTR-08 — it extends both to cover the case where a project root is genuinely plural. The pattern this feature formalizes: one root folder dedicated to one subject (a client, a family, a multi-entity business, a person managing several concurrent efforts for themselves) that contains two or more self-contained sub-project folders, plus a shared layer (drop folder, trackers, admin, cache) that all sub-projects draw on in common. Use this feature when a project genuinely has more than one separable effort running under one root, each with its own objective, its own document set, and its own natural stopping point — not merely when a single project has several workstreams or phases that all feed one outcome. If the sub-efforts are really just tracks within one unified project, this feature is the wrong fit; install FTR-08 alone and use its multi-track ID convention instead. ## Assess first - Confirm whether the project genuinely decomposes into multiple self-contained efforts, each substantial enough to warrant its own folder, document set, and (usually) its own track-ID prefix — versus a single project better served by FTR-08's ordinary multi-track convention alone. Ask the user directly if this is unclear; installing this feature where it isn't needed adds structural overhead a simpler project doesn't benefit from. - Check whether `admin\AGENT_INSTRUCTIONS.md` already has a section covering multi-sub-project structure. If present, confirm and skip. - Confirm how many sub-projects exist at install time, and get each one's short code (2-3 letters, matching FTR-08's track-code convention) and full name before writing anything — the structure depends on having this list complete and correct from the start, since renaming a sub-project after folders and trackers exist is real rework. ## Ask, only if needed If the user's request implies multiple sub-projects but hasn't stated how many or what they're called, ask directly: "It sounds like this project covers more than one separate effort — can you list them, with a short code for each (2-3 letters), and a one-line description of what each one covers?" Do not guess sub-project boundaries or names from context alone. Also ask, if not already stated: does every sub-project warrant its own drop-folder routing subfolder, or should incoming files land in one flat drop folder and be manually sorted? Both are legitimate; this is a genuine user preference, not something this feature should default silently. ## Write Add this section to `admin\AGENT_INSTRUCTIONS.md`. This is deliberately written as a set of PROJECT-SPECIFIC labeled conventions layered on top of the base catalog's own Folder Structure (FTR-07) and File Naming/Track ID (FTR-08) features — nothing here replaces those features' own mechanics; it tells the agent how to apply them when the project root is plural. ``` ◆ MULTI-SUB-PROJECT STRUCTURE This project runs [N] parallel sub-projects under one root, for [the shared subject — e.g. one client, one family, one person's several concurrent efforts]. Each sub-project is a genuinely separate effort with its own objective and its own document set — not an internal track of one unified project. SUB-PROJECT TABLE | Sub-Project | Short Code | What it covers | |------------------|------------|------------------| | [Name] | [XX] | [one-line description] | [... one row per sub-project ...] Short codes are used consistently as: - The track code in file naming, per FILE NAMING & VERSIONING (FTR-08) - A Sub-Project column in any tracker whose items span more than one sub-project (see EXCEL TRACKER PROJECT DEFAULT, below, if installed) - The subfolder name under the shared drop folder for sub-project-routed intake, if per-sub-project drop routing is in use (see DROP FOLDER SUB-PROJECT ROUTING, below) - The prefix on each sub-project's own self-contained folder SELF-CONTAINED SUB-PROJECT FOLDERS Each sub-project gets its own folder, prefixed to sort together as a distinct group from the shared root-level operating folders (e.g. a `P-` prefix tied to the sub-project's short code, or whatever prefix convention the project's own FOLDER STRUCTURE section establishes). Each sub-project folder is a minimized mirror of the root's own structure: its own docs\, drafts\, research\, correspondence\, trackers\, and archive\ subfolders. A sub-project folder MAY also hold a small number of top-level documents above its own docs\/drafts\ split — living strategy/reference documents that are actively revised rather than versioned deliverables (e.g. a master plan document) — assign these only when genuinely living/strategic, not as a way to skip normal versioning. SHARED, ROOT-LEVEL LAYER (not duplicated per sub-project) Two categories of shared material live at the project root, never duplicated inside any individual sub-project folder: - Admin (agent instructions, profiles, setup logs) — one set governs every sub-project. - Project Cache staging (whatever mechanism keeps key context loaded into every session, per FTR-15 if installed) — one staging area covering material from every sub-project, since the point of the cache is session-wide context, not sub-project-scoped context. The root's ordinary operating folders (docs, drafts, research, correspondence, trackers, archive, per FTR-07) still exist too, but are scoped to genuinely SHARED/cross-sub-project material only once this feature is installed — see CROSS-SUB-PROJECT SHARED DOCUMENTS below. Most day-to-day work happens inside a sub-project folder, not at the root, once this pattern is in place. DROP FOLDER SUB-PROJECT ROUTING (if per-sub-project routing is in use — confirmed at install time, see Ask above) The base catalog's File Storage & Transfer Rules (FTR-06) specifies one flat drop folder with no internal structure. This extends that: the drop folder contains one pound-prefixed (or otherwise clearly marked) subfolder per sub-project, matching the short codes above — one intake point at the project root, internally organized so a dropped file's sub-project is known automatically from which subfolder it landed in, no manual tagging needed, including when a file arrives from outside the agent's own session (e.g. the client or another party drops it in directly). - A file in a sub-project-routed subfolder is known to belong to that sub-project on sight. - A file dropped directly in the shared drop folder (not inside a sub-project subfolder) needs a judgment call before filing: if it clearly belongs to one sub-project, route it there (or ask); if it's genuinely cross-sub-project (see CROSS-SUB-PROJECT SHARED DOCUMENTS), it belongs at the shared root, not inside any single sub-project folder. Don't default to "unknown, ask" when the content itself makes the answer obvious. CROSS-SUB-PROJECT SHARED DOCUMENTS Some source documents aren't specific to one sub-project — e.g. general background/identifying information, or a document that legitimately supports more than one sub-project's work at once. Working rule: if a document genuinely supports more than one sub-project, it belongs at the shared root (the ordinary docs\ or research\ folder, per FTR-07), NOT filed into any single sub-project folder or duplicated across several. If it's unclear whether something is sub-project-specific or shared, ask the user rather than guessing — this determination benefits from a real example on the table, not an abstract policy decided in advance. FILE NAMING (extends FTR-08, doesn't replace it) Each sub-project's short code IS the [TRACK] segment of FTR-08's standard track document format. If a sub-project later grows complex enough to need finer functional grouping within it, extend the track code to two letters — sub-project code first, functional letter second — following whatever extension convention FTR-08 itself specifies; propose it, confirm with the user, and update both the Sub-Project Table above and FTR-08's own Track Table together, never one without the other. ONGOING RESPONSIBILITIES ADDED BY THIS FEATURE - When filing a new document, confirm (or infer from context) which sub-project it belongs to before assigning its track ID — don't default to "unknown." - Sort the shared drop folder on request, routing each file to its sub-project (or the shared root, if genuinely cross-sub-project). - If a new sub-project is ever added, or an existing one's scope changes meaningfully, update the Sub-Project Table and this section together — never let the table drift out of sync with what's actually being tracked. ``` ## What this doesn't cover - Which specific tracking mechanism (markdown two-layer, Excel, or a mix) each sub-project's trackers use — that's FTR-13/FTR-14/FTR-15/FTR-36's job, this feature only establishes that a Sub-Project column or per-sub-project file split may be needed once those features are in play across a plural project. - Legal, tax, or entity-specific handling for any individual sub-project — domain-dependent features (see the Legal category, or any future domain-specific feature) install and behave exactly as they would on a single-project setup; this feature only affects where their output lives and how their items get tagged by sub-project. - Cross-sub-project reporting/dashboards that aggregate status across all sub-projects at once — a real, useful extension of this pattern, but out of scope for this base capability; a future feature could build on this one to add it. ## Confirm Confirm: Multi-Sub-Project Awareness is installed — a MULTI-SUB-PROJECT STRUCTURE section now exists in `admin\AGENT_INSTRUCTIONS.md` naming every sub-project, its short code, its self-contained folder convention, and how the shared root layer (drop folder, admin, cache) is scoped across all of them. Want to install another, or is that everything for now?