From a3785a6ec6e6f19d06420c9f06bcb0f7510028c0 Mon Sep 17 00:00:00 2001 From: claude Date: Fri, 24 Jul 2026 23:43:53 +0200 Subject: [PATCH] docs(guide): Session trigger cadence sets emission density, not the index MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Ratifies the m37 milestone-fieldtest concern: the guide recommended a once-per-bar trigger without saying whether bars_since_open depends on it. It does not — the index is clock-derived (ctx.now()), so a denser trigger stream (raw m1 price, as the shipped corpus wires it) emits the same per-bar index more often. The once-per-bar wiring is a convention for one-emission-per-bar, not a correctness requirement. --- docs/authoring-guide.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/docs/authoring-guide.md b/docs/authoring-guide.md index 94bb315..82975b7 100644 --- a/docs/authoring-guide.md +++ b/docs/authoring-guide.md @@ -344,6 +344,14 @@ separate in-session bool — `bars_since_open` alone is the contract. DST is handled by `chrono-tz`, so the same local minute reads the same index in summer (CEST) and winter (CET). +The index is derived from the clock (`ctx.now()`), never counted from trigger +firings — so the trigger's cadence only sets how *often* the node emits, not +what it emits. Feeding a denser stream (e.g. a raw m1 `price`) is equally +valid: the node fires once per input tick and reports the same +`period_minutes`-bar index throughout that bar. The once-per-bar wiring above +is the convention when you want exactly one emission per completed bar; it is +not a correctness requirement. + Wire it like any node — `{"op":"add","type":"SessionFrankfurt","bind":{"period_minutes":{"I64":15}}}`, feed its `trigger` from a once-per-bar stream, and read `bars_since_open`.