ds-method

ds-method — The Last DS Mile Discipline Layer

Overview

Every /ds-* stage skill in this plugin inherits this shared voice. This is not a pipeline stage itself — it defines the Red Flags, Rationalizations, and Hard Gates that every stage cites, so a project can't quietly drift into leakage, inflated metrics, or unreproducible results.

When to Use

• Referenced automatically by every stage skill (ds-frame through ds-handoff) — you should not need to invoke it directly.
• Use directly when the user asks "why do I need a baseline," pushes back on a gate, or you need to decide whether a stage should stop and ask before proceeding.

Core Process

1. When a stage skill's process reaches a point covered below, check the relevant table instead of inventing new judgment calls ad hoc — this keeps behavior consistent across every stage.
2. When a discipline gate applies and its artifact is missing, produce it inline — run the prior stage's work yourself, in the same turn, and say plainly what you produced and why. Never silently work around a missing gate artifact, and never end the turn asking the user to go run a separate command first: the gate is satisfied by doing the work, not by requesting permission to do it.
3. When a safety gate applies (see below), stop and ask before proceeding — these are the cases where continuing unilaterally could be irreversible or externally visible.
4. Before running a stage's full process, climb the stage ladder: (a) does that stage's artifact already exist? if so, reuse it, don't redo it. (b) does this request actually need it, or can the ask be answered without it (see ds-method's guard against escalating a plain question)? (c) can it be satisfied in a couple of lines in the run's notes, rather than a full stage write-up? Stop at the first rung that resolves it. If you track progress with a todo list, keep one list for the whole run, not a fresh create/update pair per stage — a dozen-plus todo-tool calls for a single request is a sign the ladder above wasn't applied.
5. Pick the artifact mode once, at the start, and say which you picked:
   • Express (default for a single-shot request answered in one session — "build a model for X and tell me how it does"): write one .last-ds-mile/run.md carrying every stage's output — framing, baseline, validation choice, model comparison, evaluation/slices — as sections in that one file, not a dozen separate stages/*.md files. The gates and their evidence still all have to be there; only the file layout is consolidated.
   • Full per-stage (a genuine multi-session project, or the user asks to run a specific /ds-* stage on its own): each stage writes its own .last-ds-mile/stages/NN-name.md as described in that stage's own Core Process — this is what makes stages resumable and reviewable independently across sessions.
   • Once a project has .last-ds-mile/stages/ files, stay in full per-stage mode for consistency; don't switch an in-progress project to express mid-way.
6. When a Red Flag fires, say so out loud before continuing, even if the user seems to want to move fast — a flagged result that turns out fine costs one sentence; a leaked metric that ships costs the project's credibility.