@@ -100,6 +100,33 @@ When a companion notes repo is present, treat the live Heddle codebase as the im
100100- For releases, use annotated tags such as ` vX.Y.Z ` and write release notes from
101101 the real git range since the previous tag.
102102
103+ ## Architecture Clarification Checkpoint
104+
105+ Heddle is a coding agent runtime, and many changes touch shared runtime,
106+ workspace, session, control-plane, trace, live-event, tool, approval, memory, or
107+ interface boundaries. Do not force a working patch when ownership is unclear.
108+
109+ Before non-trivial implementation, identify the module that should own the
110+ behavior and keep the change aligned with the existing architecture documents
111+ and nearby README files. If the change would duplicate policy, re-resolve
112+ defaults or fallbacks in another layer, add a thin wrapper, introduce a parallel
113+ data flow, cross a documented dependency boundary, or make host/UI code own
114+ core semantics, stop and ask the maintainer for direction before coding.
115+
116+ When stopping, briefly explain:
117+
118+ * what task you were implementing;
119+ * which modules could plausibly own the behavior;
120+ * what existing code or docs make the ownership unclear;
121+ * what risk you see, such as duplicated policy, thin wrapper, host-side domain
122+ ownership, parallel event path, unclear persistence semantics, or boundary
123+ violation;
124+ * one or two concrete implementation options and the tradeoff between them.
125+
126+ Prefer a scoped migration that deletes or simplifies an old path over adding a
127+ new abstraction beside it.
128+
129+
103130## Public Source Of Truth
104131
105132For contributors who only have this repo:
0 commit comments