archi-feature-relations

Invocation

• Auto-invoke: No, not triggered by model based on description.
• Trigger location: Only explicitly called via [[SUBAGENT]] / [[NO-SUBAGENT]] in /archi.* protocols.
• Execution context: When subagent supported must execute in independent subagent/independent context; only downgrade to inline Skill when no subagent.
• Boundary: Only return protocol-required structured artifacts, subsequent write, confirm and signoff handled by calling protocol.

featureRelations Linkage Handler

Core Concept

Aggregator Task: Task whose core responsibility is to list / aggregate / dynamically reflect another class of Task outputs. When adding or removing source-class Tasks, aggregator Task may need sync.

Aggregator Determination Necessary Conditions (all must be met):

1. Code-level echo: Iterates / Enumerates / Dynamically loads same-type modules (for (const cmd of allCommands), Object.values(registry), Read directory then dynamic import)
2. Description-level echo: "Aggregate all X", "Register all X", "List all X", "Dynamically generate X list"

Only matches description-level but actual code is hardcoded list → Not aggregator.

Modes

register

Determine if current Task is aggregator, if so generate one featureRelations append entry.

1. Analyze task_context.spec + goal + description
2. Compare against aggregator necessary conditions all met → Aggregator; otherwise non-aggregator
3. Aggregator → Output updates: { action: "append", entry: { aggregator, sources, evidence, checkNote } }
   • aggregator: Task ID
   • sources: Source range description, prefer pattern match over enumeration (e.g. "All /archi.* command protocols" not "/archi.init, /archi.plan, ...")
   • evidence: Original sentence extracted from spec/goal, proving judgment basis
   • checkNote: "When added or removed, check if needs sync"
4. Non-aggregator → Output NOT AGGREGATOR + judgment reason (which necessary condition not hit)