docs(design): record the subproject-pattern proposal, defer promotion

home proposed promoting its subproject pattern (a folded-in standalone project living as a self-contained subdir under a parent's scope) into the rules layer. The pattern reads as sound. I deferred it on evidence rather than merit, and preserved both the proposal and home's worked instance here so the decision has its source.

Two findings drove the deferral. It's N=1: across all 27 agent scopes, home is the only project with subprojects, and all nine came from one fold. There's no second instance to say which parts are general and which are home-shaped. The placement also contradicts the proposal's own argument. Rules load into every session of every project, and the doc argues that layer is a tax paid whether or not it's relevant, with depth belonging one open away. At 282 lines it would be the third-largest rule and add ~11% to the layer, so every unrelated project would carry a one-project convention.

I want to scout which projects would actually get subprojects, and why, before shaping anything. That evidence decides whether the pattern gets dropped or adjusted.

Two things to fix if it ever promotes: the doc cites a privacy-model rule that doesn't exist (the real content is the gitignore-vs-track and public-reachability decision), and about half of it is home's instance rather than rule content.

1 files changed, 39 insertions, 0 deletions

diff --git a/todo.org b/todo.org
index 2a8a999..7c04560 100644
--- a/todo.org
+++ b/todo.org
@@ -48,6 +48,45 @@ triage-intake.org), live trial night on rulesets. Origin: work project's
 proposal, [[file:docs/design/2026-07-14-sentry-workflow-proposal.org][docs/design/2026-07-14-sentry-workflow-proposal.org]]. All nine
 design decisions resolved with Craig 2026-07-14 (recorded in the spec).
 
+** TODO [#C] Subproject pattern — promote to claude-rules? :spec:
+SCHEDULED: <2026-07-20 Mon>
+home proposes promoting its subproject pattern (a former standalone project
+folded into a parent, living as a self-contained subdir sharing the parent's
+=.ai/= scope) into the rules layer: vocabulary, the read-first
+=<subproject>/<subproject>-brief.org= convention, the parent-vs-subproject
+content criterion ("one fact, one home"), and create/archive criteria.
+Proposal + home's full instance:
+[[file:docs/design/2026-07-15-subproject-pattern-proposal.org][proposal]],
+[[file:docs/design/2026-07-15-subprojects-convention-home-instance.org][home's convention doc]].
+
+Deferred 2026-07-16 rather than promoted. *Craig's framing:* he wants to scout
+which projects would actually get subprojects, and why, before we shape a rule.
+If he hasn't done that scouting by the time this comes up, offer to do it
+together — brainstorm the candidates, then explore the reasons behind each. That
+evidence decides it: either we drop the pattern, or we know enough to adjust it
+so it's effective. Don't shape the rule before the scouting.
+
+*Review findings from the 2026-07-16 pass* (the inputs the decision needs):
+
+- *N=1.* home is the only project with subprojects, across all 27 =.ai= scopes;
+  its nine all came from the single 2026-06-11 fold. This is the fact the
+  scouting tests.
+- *Placement contradicts the proposal's own principle.* =claude-rules/*.md=
+  loads into every session of every project. home's doc argues the always-on
+  layer is "a tax paid whether or not it's relevant today" and depth belongs
+  "one open away". At 282 lines the doc would be the third-largest rule and add
+  ~11% to the always-on layer, so every .emacs.d / takuzu / chime session would
+  carry a one-project convention.
+- *Precedent for the shape:* =patterns.md= (29 lines, explicit "don't carry the
+  catalog in context") and =docs-lifecycle.md= (75 lines, depth in a spec).
+  Thin rule + on-demand depth is the established answer.
+- *Dangling reference:* the doc cites =claude-rules/git-hosting-privacy-model=
+  as authority for its shared-scope-safety criterion. No such file exists — the
+  real content is the gitignore-vs-track and public-reachability decision in
+  =protocols.org=. Fix before any promotion.
+- *Instance vs rule:* the metrics, self-improvement log, kill criteria, rollout
+  dates, and adoption table are home's instance, not rule content.
+
 ** TODO [#D] Cross-host roam conflict surfacing :feature:
 Deferred from the sentry spec (Decision: host-local lock only). The
 roam-write lock serializes same-host agents; a true cross-host race still