Year Start

Year-Ahead Scan (global, MCP-only)

Replaces the old project-local /year-start (now archived at Journals/.claude/skills-legacy/year-start/). Same reasoning as week-start/SKILL.md's header. CLAUDE.md at /Users/latuconsinafr/Personal/Trading/Journals/CLAUDE.md remains the rulebook.

If anything this session suggests a rule should change, per CLAUDE.md §20.14: add it to CLAUDE.md §21.3, do not act on it.

Context only, persists nothing to journal_rollups — same as month-start/quarter-start: the old system never wrote a file here either. It does, as of 2026-08-25, produce a real yearly technical score and fundamental digest (write_technical_score/write_fundamental_digest, timeframe 1Y) — the top of the cascade: a 1Y fundamental read feeds down through every finer timeframe that doesn't have its own more specific research yet (resolveFundamentalTimeframe in lib/pairs.ts), and the 1Y heatmap column is real, same mechanic as every other timeframe. As of 2026-08-30, it also writes validated levels (write_level, timeframe 1Y) for any zone from Step 3.2 that clears §3.3's validation bar. Still no verdict, thesis, or hypothetical — those only originate from /sod.

Step 0 — confirm the MCP server is reachable, then resolve the active set

Call get_account_state first. If it fails, stop and explain just run needs to be running. Then call get_active_instruments — do not assume a fixed instrument set below.

Step 1 — resolve the year

Use the current year, unless the pilot gives one explicitly.

Step 2 — get the required charts

Clean 1Y-equivalent and 1M (monthly) charts, per active instrument — required, same blocking pattern as sod/SKILL.md Step 3. The 1Y-equivalent is this session's own resolution and gets a real technical score (Step 4). 1M is context only — never its own write_technical_score call here; that stays month-start's (or quarter-start's refresh) write to make.

"1Y-equivalent" is deliberately not "a literal yearly candle chart" (added 2026-09-05, same reasoning quarter-start already applies to its own missing quarterly-candle resolution): MT5 has no yearly timeframe at all — MN1 is its coarsest. A genuine 12M/yearly chart exists on other platforms (e.g. TradingView) and is fine to use if the pilot already has one open, but nobody should need a second platform just for this session. Either is acceptable:

• A true yearly-candle chart, from whatever platform provides one, or
• A wide-zoomed MN1 (monthly) view spanning many years — the same chart month-start reads at its normal zoom, just pulled back to show a multi-year span instead. State plainly which one was provided; a wide-Monthly substitute doesn't change anything about how Step 3.2 is read (multi-year swing structure is multi-year swing structure regardless of which candle body encodes it), it's purely a note about provenance.

The write_technical_score/write_level calls in Step 4 are still timeframe: "1Y" either way — the cadence of the read is what "1Y" means here, not a claim about the literal candle resolution of the source image. Check charts/[DATE]/year-start/ on disk first; ask only for what's missing.

Step 3 — run the scan

1. High-level scan of known major macro themes for the year — central bank policy paths, elections, known geopolitical calendar.
2. Independent yearly technical read, per instrument, from the 1Y-equivalent chart (Step 2 — a true yearly chart or a wide-zoomed MN1 view, whichever was provided) — same §3 checklist rigor as /sod, at yearly resolution: multi-year swing structure, the handful of levels that actually matter at this scale. Then look at the 1M chart for context, informed by get_journal_rollups (period: "quarterly", recent limit) too.
3. Yearly fundamental digest, per active currency (§4, timeframe 1Y) — the broadest cadence in this practice: multi-year policy regime, not just this year's calendar. §19 sources only.

Step 4 — write through MCP

1. write_calendar_event — for each relevant event surfaced in Step 3.1. Leave timeUtc unset and say so if unverified.
2. write_technical_score — once per active instrument, timeframe: "1Y", from Step 3.2.
3. write_level at timeframe: "1Y" — THIS IS THE PRIMARY WRITE FOR THIS SESSION. Do this one before step 4, never skip it in favor of step 4. One call per zone from Step 3.2's yearly read that clears §3.3's validation bar: named prior turns, each with a date and a wick.
   • The date must be exact, obtained by counting bars from the nearest labeled gridline — never "approx," and sparse gridlines are never a reason to skip writing a level.
   • Apply the same counting effort to every pair this session — do not verify one more carefully than the others. But decide per pair, not for the session as a whole: if one pair's turn can't be dated, that one is unvalidated — it does not mean skipping every other pair that can be dated. Partial coverage is the normal, correct outcome, not a fallback.
   • A stated tolerance ("±1-2 days") is not exact and does not pass; an unvalidated pair doesn't get written with a hedge, it doesn't get written.
   • Do this by reading the image and counting candles — never by writing or running a script, pixel-measurement tool, or any automated axis calibration; that's a fragile detour, not extra rigor, and a bug in one is never a reason to write zero levels instead.
   • A zone without nameable turns stays prose-only in write_technical_score's technicalBasis.
4. write_level at timeframe: "1M" — SECONDARY, ADDITIVE TO STEP 3 ABOVE, NEVER A SUBSTITUTE FOR IT. One call per zone visible on the same Step 3.2 context read of the 1M chart that clears the same §3.3 bar (same exact-date, same per-pair rigor, same no-tooling rule as step 3). Levels are backward-looking facts, not a forward call, so this isn't restricted to this session's own 1Y write — but it only ever supplements step 3, it does not replace it. write_level upserts by overlapping price range, so this can only add to or confirm what month-start/quarter-start already logged at 1M, never contradict it silently.
5. write_fundamental_digest — once per non-metal active currency only, timeframe: "1Y", from Step 3.3. Never call this for XAU/XAG — the tool itself rejects a metal currency value now (a real mistake, happened more than once, now a hard schema error); it forces a 0-10 currency-strength scale onto something §4 explicitly wants read on a different -10..+10 risk-sentiment scale instead.
   • write_risk_sentiment, once per metal active currency, timeframe: "1Y", from Step 3.3 — as of 2026-09-03 this is the correct write for metals, not a prose-only fallback. Same timeframe parameter as write_fundamental_digest, so a yearly call no longer collides with /sod's daily call for the same currency, and it auto-populates the metal's heatmap cell the same way, once the paired currency has a score at this exact date+timeframe. Nothing else gets written this session.