◆ 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.