Week Start

Week-Ahead Scan (global, MCP-only)

Replaces the old project-local /week-start (formerly at Journals/.claude/skills/week-start/, deferring to Journals/PROMPTS.md). Same reasoning as sod/SKILL.md's header — that file and PROMPTS.md are left in place, unused. CLAUDE.md at /Users/latuconsinafr/Personal/Trading/Journals/CLAUDE.md remains the rulebook; §13 governs this cadence's cascade rule.

Instruments — resolved live via get_active_instruments, same as sod/SKILL.md. Call it in Step 0 alongside the connectivity check and use its full pair codes for every subsequent MCP call — do not assume EU/GU/UJ/XAU (used here for readability only) is still the active set.

This still sets context only — no verdict, thesis, or hypothetical. Those only ever originate from a daily (/sod) session; if asked for a directional call here, decline and point to /sod. It does, as of 2026-08-25, produce a real weekly technical score and fundamental digest for the heatmap (write_technical_score/write_fundamental_digest, timeframe 1W) — that's scoring, not a trading decision, and the distinction stays absolute: a number on the heatmap is not a verdict. As of 2026-08-30, it also writes validated levels (write_level, timeframe 1W) for any zone named in Step 4.2 that clears §3.3's validation bar — get_active_levels has no timeframe filter, so a weekly level surfaces on the "levels to watch" widget alongside daily ones from /sod.

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

Same as every other skill in this set — call get_account_state first. If it fails, stop, explain just run needs to be running in webapp/, and do not proceed as if anything here will be recorded. Then call get_active_instruments and use its result for the rest of this session — do not assume the EU/GU/UJ/XAU shorthand used below still matches the active set.

Step 1 — resolve the week

Compute the ISO week with date +%G-W%V (confirmed empirically 2026-08-19 to zero-pad correctly, e.g. 2026-W34, 2026-W02 for single-digit weeks) — unless the pilot gives one explicitly. Never hand-construct this string — get_journal_rollups sorts periodKey as plain text, and an unpadded week number (2026-W5) sorts in the wrong place relative to 2026-W31. This is not cosmetic; getting it wrong silently corrupts every cascade read that follows.

Step 2 — check whether this week's scan already exists

Call get_journal_rollups (period: "weekly", small limit, e.g. 4). If a row for this exact week's periodKey already has weekAheadScanMd set, confirm with the pilot before overwriting rather than silently replacing it.

Step 3 — gather what the scan needs

• From the same get_journal_rollups call: the immediately prior week's overviewMd (the highest periodKey strictly less than this week's), for the "has anything shifted since last week" comparison. If none exists yet (this is early in the practice), say so plainly — there's nothing to compare against yet, not an error.
• get_calendar_events for the days in the week ahead, per currency in the active set (Step 0's get_active_instruments) — or ask the pilot for anything not yet on file if this is being run before that research has happened.
• Clean 1W (weekly) and 1D (daily) charts, per active instrument — required, same blocking pattern as sod/SKILL.md Step 3. 1W is this session's own resolution and gets a real technical score (Step 5). 1D is context only — "has structure shifted since last week's daily reads" — never its own write_technical_score call; that stays /sod's exclusive write, every single day. Check charts/[DATE]/week-start/ on disk first, same convention as sod Step 3; ask only for what's missing.

Step 4 — run the scan, in this order

1. Scan the economic calendar for the full week ahead across every active instrument — flag every high-impact event with its scheduled time (WIB, plus server and ET). Every time and date comes from the calendar itself (§19 primary sources) — leave a forecast/previous value blank and say so if it can't be verified, never guess.
2. Independent weekly technical read, per instrument, from the 1W chart — same §3 checklist rigor as /sod applies to D1/H4/M15, just at weekly resolution: swing structure, the nearest validated levels, volume where it confirms/contradicts. This is a real technical score, not a verdict — no thesis is asked for, no entry/stop/target gets discussed. Then look at the 1D chart for context only: has anything shifted since last week's overview (Step 3)? Name the next level above and below current price, not just the nearest one, so the week's R:R arithmetic has something to work with once a daily session finds a setup.
3. Weekly fundamental digest, per active currency (§4, timeframe 1W) — deeper research than a daily digest affords: this week's actual data/speaker calendar (Step 4.1) plus the broader policy/growth picture. §19 sources only, same as every other fundamental digest in this practice.
4. Note any event-risk windows (§6) to be aware of early in the week, and which sessions are actually unobstructed by them.
5. Flag which days carry a red-folder release, so /sod//eod know to capture M15 on those days regardless of position status (§6's measurement-method requirement).

Step 5 — write through MCP (the only write path)

1. write_calendar_event — for each relevant event surfaced in Step 4.1. Leave timeUtc unset and say so if it isn't verified against a primary source.
2. write_technical_score — once per active instrument, timeframe: "1W", from Step 4.2's independent weekly read. Never call this with timeframe: "1D" — that upserts into /sod's own cell and isn't this session's write to make.
3. write_level at timeframe: "1W" — 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 4.2's weekly read that clears §3.3's validation bar: named prior turns, each with a date and a wick, not just "resistance around X."
   • The date must be exact, obtained by counting bars from the nearest labeled gridline — never "approx" or rounded to the nearest label, 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 (levels for some pairs, prose-only for others) 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 mentioned in the technical read but without nameable turns stays prose-only in write_technical_score's technicalBasis — do not force a write_level call just to cover every level named informally.
4. write_level at timeframe: "1D" — SECONDARY, ADDITIVE TO STEP 3 ABOVE, NEVER A SUBSTITUTE FOR IT. One call per zone visible on the same Step 4.2 context read of the 1D 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 (validated prior turns), not a forward call, so unlike write_technical_score this one isn't restricted to /sod's own timeframe — but it only ever supplements step 3, it does not replace it. A pair+timeframe can hold several levels at once, and write_level upserts by overlapping price range, so re-confirming a level already on file merges evidence rather than duplicating it.
5. write_fundamental_digest — once per non-metal active currency only, timeframe: "1W", from Step 4.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, not just a documented "don't"); it forces a 0-10 currency-strength scale onto something CLAUDE.md §4 explicitly wants read on a different -10..+10 risk-sentiment scale instead.
   • write_risk_sentiment, once per metal active currency, timeframe: "1W", from Step 4.3 — as of 2026-09-03 this is the correct write for metals, not a prose-only fallback. It now takes the same timeframe parameter as write_fundamental_digest (same enum, same default), so a weekly call here no longer collides with /sod's daily call for the same currency — they're distinct rows. It also auto-populates the metal's heatmap cell the same way write_fundamental_digest does for non-metal pairs, once the paired currency has a score on file at this exact date+timeframe.
6. write_journal_rollup — period: "weekly", this week's periodKey, weekAheadScanMd only (the Step 4 scan content). Do not set overviewMd/reflectionMd/compliance fields here — those belong to week-end, and setting them now with placeholder content would corrupt what week-end writes later (the upsert merges by field, so leaving them unset here is what keeps week-end's later write clean, not a limitation to work around).

If either call fails, stop and report exactly what succeeded and what didn't, rather than silently treating the scan as fully recorded.