@turri-dev/cli 0.1.6-next.336dd6e → 0.1.7-next.9aec40e

package/dist/regenerate/spec-map.d.ts

@@ -0,0 +1,138 @@
+import { type MarshalledPlainSource } from "../plain/spec.ts";
+import { type MapCodebase, type MapPlan, type MapPulse } from "./loop.ts";
+/**
+ * The regeneration: the spec itself, with the build drawn onto it - see docs/using.md.
+ *
+ * Nothing new is stored. A page a module, read from what turri keeps already: the code record (what is built, and the
+ * old side of each change), the .plain files now (the lines, and what differs), the tests record (which functional
+ * specs have conformance tests) - so the map is right from the files alone, the moment turri opens a project. The work
+ * loop's plan is laid over it (`markSpecMap`): the pulse regenerating each item, the pulse planned to, or why there is
+ * none.
+ *
+ * An item is what turri plans and diffs by: a definition, a req, a functional spec with its sub-bullets and acceptance
+ * tests. Items are matched to pulses by their lines in the trees each pulse goes between, as the loop has them.
+ */
+/** Where an item stands against the code record. A test req is the conformance track's: it is never built. */
+export type ItemState = "built" | "new" | "changed" | "removed" | "test";
+export interface MapItem {
+    /** Stable while the item reads the same: what the cursor stays on. */
+    key: string;
+    section: string;
+    /** The imported file it is written in, as shown; undefined, the module's own file. */
+    file?: string;
+    state: ItemState;
+    /** Its text now - for one taken out, the code record's. */
+    text: string;
+    /** The code record's text, for a changed item. */
+    was?: string;
+    /** Its acceptance tests, as the spec has them now. */
+    acceptance: string[];
+    /** Its line in the code's tree now, and in the code record's: what a pulse's trees are matched by. */
+    line?: string;
+    wasLine?: string;
+    /** A functional spec's conformance tests: written for it as it reads now, for an earlier text, or for one taken out. */
+    tests?: "now" | "older" | "removed";
+}
+export interface MapPage {
+    module: string;
+    plainFile: string;
+    /** The codebase its code lives in: whose record it is read from, and whose pulses regenerate it. */
+    buildDir: string;
+    /** The files it imports, as shown, in the order it reads them. */
+    imports: string[];
+    /** The module it requires - whose code it is built on - when it requires one. */
+    requires?: string;
+    /** Its conformance tests are on, as its config has it: `conformance-tests:` is not false. */
+    conformance?: boolean;
+    items: MapItem[];
+    /** Its spec does not parse, or could not be read. */
+    error?: string;
+}
+/** An item's mark in the gutter. */
+export type Mark = "built" | "regenerating" | "planned" | "waiting" | "planning" | "stuck" | "removing" | "none";
+export interface MarkedItem extends MapItem {
+    mark: Mark;
+    /** The pulse regenerating it, or planned to: running, or its provisional number. */
+    pulse?: MapPulse;
+    /** In the pulse that did not land: that pulse's number - rolled back, and waiting. */
+    rolledBack?: number;
+    /** A conformance pulse is writing its tests now. */
+    testing?: boolean;
+    /** The conformance pulse planned to write its tests, not running yet: what its provisional number is read from. */
+    testsPulse?: MapPulse;
+}
+export interface MarkedPage extends MapPage {
+    items: MarkedItem[];
+    /** The loop looks after its codebase: something asked for it. */
+    tracked: boolean;
+    /** Its codebase, as the loop has it. */
+    codebase?: MapCodebase;
+    /** The top line's reason: what is happening, or why nothing is. */
+    status: string;
+    /** It needs the person: halted, or the planner found no plan, or its spec does not parse. */
+    stuck: boolean;
+}
+/**
+ * A module's items, from what its code is built from and what its spec says now: every item of the spec in its place,
+ * each built, new or changed, and between them the items taken out that the code still has.
+ *
+ * `spec` and `record` are the codebase's trees - the module's items untagged when `own`, tagged with it otherwise. `full`
+ * is the spec with its acceptance tests and test reqs.
+ */
+export declare function pageItems(input: {
+    module: string;
+    own: boolean;
+    spec: MarshalledPlainSource;
+    record: MarshalledPlainSource | null;
+    tested?: MarshalledPlainSource | null;
+}): MapItem[];
+/** A spec file as the map names it: a template of turri's standard library by its import path, others from the project. */
+export declare function importLabel(path: string, projectDir: string, stdlibRoot?: string): string;
+/**
+ * The items laid out as the files have them: the module's own file first - its sections in its order, its definitions
+ * in its order - then each file it imports, the same way. A ghost keeps its place after the item before it.
+ */
+export declare function layOut(items: MapItem[], files: Array<{
+    label?: string;
+    text: string;
+}>): MapItem[];
+/**
+ * The pages of the files given, from the files alone: one a module of each file's requires chain, bottom first, each
+ * once. A module below the furthest-built one is read from that one's codebase, whose record has every module's items;
+ * a module above it from its own, empty until its turn comes.
+ */
+export declare function readSpecMap(files: string[]): MapPage[];
+/** The pages, and the files they were read from: while none of them changes, the pages read the same. */
+export declare function readSpecMapWithDeps(files: string[]): {
+    pages: MapPage[];
+    deps: string[];
+};
+/** The count a page's top line starts with: how many of its functional specs are built as the spec has them. */
+export declare function countOf(page: MapPage): {
+    built: number;
+    total: number;
+};
+/**
+ * The plan laid over the pages: each item that differs from the code marked with the pulse regenerating it, the pulse
+ * planned to, or - with none - planning, stuck or waiting; and each page's reason on its top line.
+ */
+export declare function markSpecMap(pages: MapPage[], plan: MapPlan): MarkedPage[];
+/**
+ * The .plain files the map shows when nothing has been asked for: the project's module from config.turri.yaml, else the
+ * .plain files in the folder that no other one there imports or requires.
+ */
+export declare function defaultMapFiles(cwd: string): string[];
+/**
+ * The map as the side panel reads it on every frame: read again from the files and laid over the plan at most every
+ * `every` ms - git runs for the records and the diffs - and the same pages in between.
+ */
+export declare function createSpecMapSource(options: {
+    files: () => string[];
+    plan: () => MapPlan;
+    every?: number;
+    now?: () => number;
+}): {
+    read(): MarkedPage[];
+    /** Read the files again on the next frame, whatever they look like. */
+    refresh(): void;
+};

package/dist/regenerate/spec-steps.d.ts

@@ -0,0 +1,137 @@
+import { type MarshalledPlainSource } from "../plain/spec.ts";
+/**
+ * The steps from one spec to another: a sequence of spec diffs that, rendered one after the
+ * other, take code built from the first spec to code built from the second.
+ *
+ * Both specs are marshalled trees, written out as text with one JSON value per line - a
+ * section's name, then each of its items on a line of its own - and compared with git. So an
+ * item is the unit of change: a functional spec with its acceptance tests and linked resources,
+ * a definition, a req. Git lines them up, so a spec inserted in the middle is one addition and
+ * the specs after it are untouched, though their numbers moved.
+ *
+ * The planner (`chunk-plan.ts`) cuts the changes into steps - which go together, which go first. It
+ * picks changes by id; it never writes a diff. `makeStep` applies what it picked, and `inconsistencies`
+ * checks that each step leaves a spec that holds together - no concept used before a step defines it.
+ */
+/** The sections of a tree, in the order they are written. Written even when empty, so they never change. */
+export declare const TREE_SECTIONS: string[];
+/**
+ * A tree as text: each section's name on a line - `["definitions"]` - then one JSON value per
+ * item, keys sorted. No commas and no brackets around a section, so adding an item at the end
+ * changes nothing before it.
+ */
+export declare function serializeTree(tree: MarshalledPlainSource): string;
+/**
+ * Whether two trees are the same spec, however it is laid out across files: the definitions, the
+ * implementation and test reqs the same - in any order, from the module's own file or an imported
+ * one - and the functional specs the same, in order, those it inherits then its own, whichever
+ * module each is written in. Specs moved between a module and the ones it requires are the same
+ * spec: the code holds them all. But a module required now that was not before is not - its code
+ * is not in this codebase - so `after` may only drop required modules, never gain one.
+ *
+ * What it takes to tell a restructuring of the specs - definitions moved to a common module,
+ * sections reordered - from a change: one of these has nothing to render.
+ */
+export declare function sameSpec(before: MarshalledPlainSource, after: MarshalledPlainSource): boolean;
+/** A serialized tree read back. A known section with no items is left out, as the parser leaves it. */
+export declare function parseTree(text: string): MarshalledPlainSource;
+/** git's diff of two serialized trees, with `context` lines around each change. */
+export declare function diffTrees(before: string, after: string, context?: number): string;
+/**
+ * One change between two serialized trees: an item added, removed, or changed in place. Where it
+ * goes is given in the lines of the tree it applies to, so any selection of changes applies to
+ * that tree on its own, in any order.
+ */
+export interface SpecChange {
+    id: string;
+    /** The section the item is in. */
+    section: string;
+    kind: "add" | "remove" | "change";
+    /** The item's line as it is, for a removal or a change. */
+    before?: string;
+    /** The item's line as it becomes, for an addition or a change. */
+    after?: string;
+    /** Its number in its section, from 1: where it is now, or - for an addition - where it lands in the target. */
+    position: number;
+    /** The line it removes, in the tree it applies to. */
+    removes?: number;
+    /** The line it goes in front of, and its place among others that go there. */
+    inserts?: {
+        at: number;
+        order: number;
+    };
+}
+/** The changes that take one serialized tree to another, in the order git lists them. */
+export declare function changesBetween(before: string, after: string): SpecChange[];
+/** How alike two items are: the share of their words they have in common. */
+export declare function similarity(a: string, b: string): number;
+/** A selection of changes, applied to the serialized tree they were found in. */
+export declare function applyChanges(before: string, changes: SpecChange[]): string;
+/** A serialized tree as a person reads it, section by section. */
+export declare function treeText(serialized: string): string;
+/** A change as the planning agent is shown it. */
+export declare function describeChange(change: SpecChange): string;
+/** One step of the sequence: a spec diff, and the spec before and after it. */
+export interface SpecStep {
+    title: string;
+    reason: string;
+    /** The changes it makes. */
+    changes: SpecChange[];
+    /** The spec before and after it, serialized. */
+    before: string;
+    after: string;
+    /** The spec after it, as a tree: what a render of this step builds from. */
+    tree: MarshalledPlainSource;
+    /** git's diff of `before` to `after`, as serialized. */
+    diff: string;
+    /**
+     * The same change as a person - or a coding agent - reads a spec change: git's diff of the spec
+     * before and after, written out as ***plain text, section by section.
+     */
+    textDiff: string;
+    /** The sections it changes. */
+    sections: string[];
+    /** Made by the harness for what the agent never placed, after its rounds ran out. */
+    fallback?: boolean;
+}
+/**
+ * What makes a spec not hold together that neither end already has: a concept used before any
+ * step defines it, or defined twice - the parser's own concept checks.
+ */
+export declare function inconsistencies(tree: MarshalledPlainSource, endpoints: Set<string>): string[];
+/** How the module's `.plain` file is laid out, for writing a tree out as that file would have it. */
+export interface SpecLayout {
+    /** Everything before the first section: the frontmatter, imports and requires. */
+    preamble: string;
+    /** The sections, in the order the file has them. */
+    sections: string[];
+    /** Each concept's place in the file's definitions - the parser orders them by what uses what. */
+    concepts: Map<string, number>;
+    /** The sections whose items the file writes with no blank line between them. */
+    tight: Set<string>;
+}
+export declare function layoutOf(text: string): SpecLayout;
+/**
+ * A serialized tree as the module's `.plain` file would have it: only its own sections, and only
+ * the ones with something in them. The functional specs it inherits are the required modules'
+ * - `required functional specs` is the parser's key for them, not a section anyone writes. With
+ * the file's layout, it is written as the file is: its preamble, its sections in its order, a
+ * blank line between items, and the definitions in the file's order rather than the parser's -
+ * so a spec diff reads as an edit to the file, at the file's line numbers.
+ */
+export declare function plainText(serialized: string, layout?: SpecLayout): string;
+/** git's diff of two serialized trees, as ***plain text - see plainText. */
+export declare function diffSpecText(before: string, after: string, file?: string, layout?: SpecLayout): string;
+/** The linked resources of a changed item whose content is different now - each hashed on its own: by their path, with both hashes. */
+export declare function resourcesChanged(before: string | undefined, after: string | undefined): Array<{
+    target: string;
+    was?: string;
+    now?: string;
+}>;
+/**
+ * The linked resources a step's changes find changed, as a diff of their own beside the spec's: a file the spec links
+ * holds something else now, though the spec's text may read as it did. The trees keep each one's hash, not what it
+ * held before - so the hunk says that it changed, and what it holds now is the file itself.
+ */
+export declare function resourceDiff(changes: SpecChange[], file?: string): string;
+export declare function makeStep(title: string, reason: string, changes: SpecChange[], before: string, after: string, file: string, layout?: SpecLayout): SpecStep;

package/dist/regenerate/state.d.ts

@@ -0,0 +1,20 @@
+import { DEFINITIONS, NON_FUNCTIONAL_REQUIREMENTS, TEST_REQUIREMENTS, type MarshalledPlainSource } from "../plain/spec.ts";
+/**
+ * A module's spec as the prompts read it: the sections every functional spec shares, and a
+ * functional spec a module inherits. What the code and the tests are built from is in `records.ts`.
+ */
+/** The sections a module shares across all its functionalities, as text. */
+export interface SharedSections {
+    [DEFINITIONS]: string[];
+    [NON_FUNCTIONAL_REQUIREMENTS]: string[];
+    [TEST_REQUIREMENTS]: string[];
+}
+/** A functional spec of a module this one requires: documented, not built here. */
+export interface RequiredSpec {
+    module: string;
+    frid: string;
+    spec: string;
+    acceptanceTests?: string[];
+}
+/** A module's shared sections as they stand, with or without a functional spec to read them through. */
+export declare function sectionsOf(tree: MarshalledPlainSource): SharedSections;

package/dist/regenerate/steer.d.ts

@@ -0,0 +1,34 @@
+/**
+ * How the person wants the queue planned - which functional specs go together, what goes first, how big a job is -
+ * given to the planner's agents with every plan, as a strong preference.
+ *
+ * It comes from three places. The conversation sets it (`steer`), for the whole project or one module, and it
+ * holds for the session. The project's AGENTS.md can say it once for good: a section whose heading names the queue
+ * ("## Queue guidance") is read with every plan, so an edit to it holds from the next. And whatever queues work can
+ * pass guidance for that work (a tool's `guidance`), which the queue keeps with it.
+ */
+/** Everything the conversation's steering applies to: every module of the project. */
+export declare const EVERY_MODULE = "*";
+export interface SteeringStore {
+    /** The steering for a scope - a module's name, or EVERY_MODULE - in the order it was given. */
+    get(scope: string): string[];
+    set(scope: string, texts: string[]): void;
+    scopes(): string[];
+}
+export declare function createSteeringStore(): SteeringStore;
+/** A module's name as the steering names it: its spec file's name, without `.plain`. */
+export declare function moduleNameOf(plainFile: string): string;
+/**
+ * What an AGENTS.md says of the queue: every section whose heading names it - "Queue", "Queue guidance", "How the
+ * render queue is planned" - up to the next heading of its level or above. Empty when there is none.
+ */
+export declare function queueSectionOf(markdown: string): string;
+/** The steering a plan of this spec's codebase follows - AGENTS.md's, then the conversation's for every module and for this one. */
+export declare function steeringFor(plainFile: string, cwd: string, store: SteeringStore): Steering[];
+/** How the person or the harness wants the queue planned: a strong preference, each with where it came from. */
+export interface Steering {
+    source: string;
+    text: string;
+}
+/** The steering, for an agent's task: each with where it came from, and how binding it is. */
+export declare function steeringBlock(steering: Steering[] | undefined): string[];

package/dist/regenerate/steering.d.ts

@@ -0,0 +1,56 @@
+import { type MarshalledPlainSource } from "../plain/spec.ts";
+import { type SpecChange } from "./spec-steps.ts";
+/**
+ * JobSteering a running code job: the spec changed while it regenerates, inside what it is regenerating - a functional
+ * spec it builds reworded, a sub-bullet added under one, a definition or an implementation req it is given edited, a
+ * file one links edited - and the coding agent is told, rather than the job stopped or the change left to the next
+ * one. A new or removed item is not a steer: the work changes shape, and that is the next job's. At most MAX_STEERS a
+ * job; the one after is the next job's, or stops this one, as `allow-to-stop-jobs` says.
+ *
+ * Three trees. `target`: what the job lands as built from - its code record. `agent`: what its agent is to build -
+ * the target, and a definition or req edited that functional specs built before the job use too: the agent is told,
+ * but the record keeps what those were built from, so the loop patches them - this one's with them - once it lands.
+ * `told`: what the agent has been told. A steer is waiting while `told` is not `agent`; edits made before it is
+ * given are one steer, the newest of each item.
+ */
+export declare const MAX_STEERS = 2;
+export interface JobSteering {
+    target: MarshalledPlainSource;
+    agent: MarshalledPlainSource;
+    told: MarshalledPlainSource;
+    /** Steers so far: each counted as it is made - edits merged into one waiting are one. */
+    steers: number;
+    /** What each steer was, in a line, for the job's report. */
+    notes: string[];
+    /** Set by the running job while its coding agent can be reached: tells it now, in its turn, and says whether it could. */
+    deliver?: (text: string) => boolean;
+    /** The module whose codebase it regenerates: the change is told with each item's module (`describeSpecChange`). */
+    module?: string;
+}
+export declare function createSteering(tree: MarshalledPlainSource, module?: string): JobSteering;
+/** What the agent is to be told and has not been: the steer waiting, or undefined when there is none. */
+export declare function waitingSteer(steering: JobSteering): string | undefined;
+/** The agent has it now. */
+export declare function markTold(steering: JobSteering): void;
+/** The message a steer is: the change since it was last told, as its first one was - and to make the code match. */
+export declare function steerText(changes: SpecChange[], moduleName?: string): string;
+/**
+ * The part of `changes` - from a tree the job regenerates towards, to the spec - that steers it: changes to items it
+ * already has, never one added or removed. A functional spec only when it is one of the job's own (`mine`, as the job
+ * regenerates it); a definition or an implementation req always. `shared`: those of them that functional specs built
+ * before the job (`built`) use too - the agent is told, but they stay out of the record.
+ */
+export declare function steerableChanges(changes: SpecChange[], mine: Set<string>, built: string[]): {
+    steer: SpecChange[];
+    shared: SpecChange[];
+};
+/**
+ * Steer a job, when the spec moved on inside what it regenerates: the trees it moves to, or undefined when nothing in
+ * the change steers it. `toSpec(tree)` is the work from a tree to the spec, as the job's track sees it; `own` the job's
+ * changes, from its record `from` to what it regenerates towards now.
+ */
+export declare function steer(steering: JobSteering, from: MarshalledPlainSource, own: SpecChange[], toSpec: (tree: MarshalledPlainSource) => SpecChange[]): {
+    target: MarshalledPlainSource;
+    agent: MarshalledPlainSource;
+    steered: SpecChange[];
+} | undefined;

package/dist/regenerate/stop-report.d.ts

@@ -0,0 +1,43 @@
+import type { SpecConflict } from "./activity.ts";
+import type { RenderConformanceTestsResult } from "./conformance.ts";
+import type { MissingToolchain, TestRun } from "./testing.ts";
+/**
+ * What to tell the person when a build gives up.
+ *
+ * A build stops at one of three gates - its unit tests, its conformance tests, or the tests of
+ * what was built before it - after the harness has tried as many times as it will. "Stopped at
+ * regression" says where, not why, and not what to do; this says all three, in the words of
+ * someone who has not read the harness.
+ */
+export type StopPoint = "unit tests" | "conformance" | "regression";
+/** How many times each gate is tried before a build stops there. */
+export declare const ATTEMPTS: Record<StopPoint, number>;
+export interface StopFacts {
+    moduleName: string;
+    /** The functionality it stopped at; none for a spec change. */
+    frid?: string;
+    at: StopPoint;
+    /** The unit test runs, the last of which is the failing one. */
+    runs?: TestRun[];
+    conformance?: Pick<RenderConformanceTestsResult, "runs" | "rounds" | "specConflict" | "stuck" | "environment" | "escalation" | "review" | "unlabelled">;
+    /** Repairs made to earlier functionalities' code before it gave up. */
+    repairs?: number;
+    /** How many times the harness judged it before it stopped - the unit tests' attempts. */
+    attempts?: number;
+    /** The unit testing script could not run: what it needs is not installed where it runs. */
+    missingToolchain?: MissingToolchain;
+    /** The unit tests passed in the end, and the unit testing script's static checks - which count as the tests do - did not. */
+    staticChecks?: boolean;
+}
+/**
+ * Where it stopped, why, and what to do about it - for the person, in a few lines, and in terms
+ * of the spec. The spec is all the person works on: the code is generated from it, so every fix
+ * offered here is a change to a `.plain` file, never to code, tests or the machine.
+ */
+export declare function describeStop(facts: StopFacts): string;
+/**
+ * A spec that contradicts itself, for the person: exactly which two functional specs, as they
+ * read, and what cannot hold - then that the decision is theirs. Nothing about code or tests: the
+ * spec is all they work on, and the fix is theirs to choose.
+ */
+export declare function describeSpecConflict(conflict: SpecConflict): string;

package/dist/regenerate/submit-work.d.ts

@@ -0,0 +1,42 @@
+import { type ToolDefinition } from "@earendil-works/pi-coding-agent";
+/**
+ * The work, handed over for review: what the agent that did it says it did.
+ *
+ * A reviewer kept through a job reads the work once, then only what changed since - and a diff says what changed,
+ * not why, nor which of the problems it raised a change answers, nor which ones the agent chose not to take up. So
+ * the agent that did the work ends each turn that goes to review with an account: what it did, and for each problem
+ * the last review raised, whether it fixed it or declined it, why, and where. The account is a claim: the reviewer
+ * gets it beside the diff the harness takes itself, never instead of it, and checks the one against the other.
+ */
+export interface WorkAnswer {
+    /** The problem's number, as the review's list gave it. */
+    problem: number;
+    outcome: "fixed" | "declined";
+    why: string;
+    files?: string[];
+}
+export interface WorkAccount {
+    summary: string;
+    answers: WorkAnswer[];
+}
+/** What the agent is told, at the end of its task: how it hands its work over. */
+export declare const SUBMIT_WORK_NOTE: string[];
+/** What the agent is told with a review's problems: how it answers them. */
+export declare const SUBMIT_AFTER_REVIEW: string[];
+/** The tool, and what was handed over through it since the harness last took it. */
+export interface WorkLedger {
+    tool: ToolDefinition;
+    /** What was handed over since the last take, left where it is. */
+    peek: () => WorkAccount[];
+    /** What was handed over since the last take - and from now, nothing. */
+    take: () => WorkAccount[];
+}
+export declare function createWorkLedger(): WorkLedger;
+/** The problems, numbered from 1, that no account answered. */
+export declare function unanswered(accounts: WorkAccount[], problems: number): number[];
+/** The prompt that sends the agent back once for the problems its account left out. */
+export declare function unansweredPrompt(numbers: number[]): string;
+/** The accounts, for the reviewer: labelled as a claim, the problems they answer named. */
+export declare function describeAccounts(accounts: WorkAccount[], problems?: Array<{
+    what: string;
+}>): string;

package/dist/regenerate/test-kinds.d.ts

@@ -0,0 +1,42 @@
+/**
+ * The two kinds of test the conformance step writes, and how each is told apart in the code.
+ *
+ * Conformance tests are written from the functional spec itself: what the functionality does,
+ * its edge cases, its errors - as if no acceptance tests had been given. Acceptance tests are the
+ * ones the spec's author wrote, each implemented as a test of its own, doing what it says. The
+ * two are kept apart even when the acceptance tests would seem to cover the functionality: tests
+ * derived only from the acceptance tests check what the author thought to check, and nothing
+ * the spec says beyond it.
+ *
+ * Each kind is labelled where anyone reading the tests can see it - in its file names, and in a
+ * comment the harness looks for - so which test is which, and which acceptance test a test
+ * implements, never has to be guessed.
+ */
+export declare function conformanceLabel(frid: string): string;
+export declare function acceptanceLabel(frid: string, n: number): string;
+/** An acceptance test as the spec gives it, without its bullet. */
+export declare function acceptanceText(item: string): string;
+/**
+ * What is missing from the labelling of a functionality's tests: the conformance label, when no
+ * test file carries it, and each acceptance test no test is labelled as implementing.
+ */
+export declare function missingTestLabels(testsDir: string, frid: string, acceptanceTests: string[]): string[];
+/** Sent back when the labels are missing: which, and how to label them. */
+export declare function labelsPrompt(frid: string, missing: string[], empty?: boolean, hasAcceptance?: boolean): string;
+/**
+ * Sent back when the labels of several functionalities are missing - a spec change that touches them: every one that is
+ * missing, in one request, so none is asked for in place of another.
+ */
+export declare function labelsPromptFor(items: Array<{
+    frid: string;
+    missing: string[];
+}>, empty?: boolean, hasAcceptance?: boolean): string;
+/**
+ * Conformance and acceptance tests in the code folder, where they do not belong: they live in the
+ * module's tests folder, which the harness runs as the conformance suite. Found by their label, or
+ * by a test file under a name or folder that says conformance or acceptance - one written without
+ * a label is misplaced all the same.
+ */
+export declare function misplacedConformanceTests(codeDir: string): string[];
+/** Sent back when there are: to the agent writing the code, or to the one writing the tests. */
+export declare function misplacedTestsPrompt(files: string[], codeDir: string, testsDir?: string): string;