/**
 * The tddMode = false variant of the implement-feature algorithm: tests
 * are written IN THE SAME STEP as the feature code, then executed and
 * repaired until green. No red is ever observed — neither for the
 * acceptance test (it is authored as the slice's specification but first
 * executed at hand-off) nor for the layer tests. Accepted trade: nothing
 * proves any test CAN fail, so a vacuous test goes unnoticed. What IS
 * proven, at the end of each slice once the UI exists, is that the
 * acceptance DRIVER executes — a wrong selector or broken Given step is
 * found and fixed here, not by the user at hand-off.
 *
 * Overrides (TddModeOverrides) can swap individual test levels to
 * test-first — per participant (every inner loop of a client or the
 * backend) or per single loop, down to the acceptance level:
 * "web-frontend-acceptance": true opens each slice with that platform's
 * red-check even in this variant (and skips its slice-end driver
 * dry-run, exactly as in the strict one). A participant key never reaches the
 * acceptance level — outer discipline changes only when named
 * explicitly (resolveTestFirst in types.ts). Remote-tested clients run
 * their loops BATCHED (see feature-loops.ts).
 *
 * Everything else is the same shape as the TDD variant: slices, the
 * contract with renegotiation, the parallel fan-out, checklists with
 * independent review, the join, real-API wiring with fake-vs-real
 * verification, mobile smoke, per-slice commits, and the hand-off.
 *
 * Read this file top-to-bottom as one algorithm; the loop shapes live in
 * feature-loops.ts and the mode-independent machinery in shared.ts.
 */
import { type FeatureRunReport, type RunDeps } from "./shared.js";
import { type TddModeOverrides } from "./types.js";
export declare function implementFeatureBasic(deps: RunDeps, featureFilePath: string, report: FeatureRunReport, extraInstructions?: string, overrides?: TddModeOverrides, runSmoke?: boolean): Promise<void>;