pi-ext

// Stage prompts are the per-invocation part of a /system turn. The invariant
// contracts (documents, Markdown, board, exec) ship as skills under ./skills so
// they enter context once on demand instead of with every stage message.

const INFER_INTENT =
	"When no instructions were supplied, infer intent with focused questions or selection before writing.";

const STAGE_PROMPTS: Readonly<Record<string, string>> = {
	init: `Initialize .system only after explicit human approval.
Inspect current project docs and rules first.
Ask focused questions for missing project truth.
Never overwrite existing core law silently.
The /system init command updates config and board schema markers mechanically.
When it reports a prior config schema, migrate existing bundles to schema 0 and the current contracts.
Preserve current meaning where compatible; do not preserve obsolete bundle fields or add runtime migration code.`,
	doctor: `Diagnose .system without mutation.
Run the deterministic doctor and explain each finding.
Do not initialize, repair, rename, delete, or rewrite files.`,
	research: `Develop terse research bundles as context requires.
Collect technical or domain knowledge vital to the project.
Record facts, sources, conclusions, and unresolved questions only.
If relevant specs exist, ask whether later specs should reference the research; research bundles never link to stages.
${INFER_INTENT}`,
	spec: `Create or amend terse specs as context requires.
Capture high-level intent, scope, behavior, constraints, and acceptance criteria.
Every spec models its behavior visually with at least one diagram, mockup, or state model; a prose-only spec is incomplete.
Use mockups for visual elements, UI, layout, and interactions, and diagrams for structure, flow, states, and relationships.
Persist accepted visual assets and their required local dependencies inside the spec bundle.
Link or embed them from index.md, and encode accepted feedback as behavior and constraints.
Do not prescribe implementation.
Specs may reference research.
${INFER_INTENT}`,
	"spec-verify": `Verify a spec experimentally.
Find logical inconsistencies, holes, risky claims, or false assumptions.
Use ephemeral probes only.
Produce evidence and proposed spec amendments; do not create a canonical bundle.
${INFER_INTENT}`,
	assess: `Assess current implementation progress for the requested specs, plans, and issues.
Inspect current code and tests deeply enough to justify each proposed state.
Do not edit bundles or .system/board.json.
Submit the assessment through system_board_propose.
Omit items whose state cannot be assessed responsibly.
${INFER_INTENT}`,
	phase: `Inspect MISSION and the current phase first.
Create, amend, or transition one terse project-wide operating phase as context requires.
A phase is a sub-mission and decision posture for an epoch, never a work breakdown or delivery milestone.
Capture its sub-mission, ranked priorities, decision defaults, explicit non-goals, and observable exit criteria.
Decision defaults cover concerns such as compatibility, migrations, stability, quality, speed, experimentation, and debt only when relevant.
If it contains implementation steps, move those steps to a plan.
Use a short label suitable for the Pi footer.
When transitioning, create or amend the phase first, then update config currentPhase only after explicit human confirmation.
Do not mutate MISSION.
${INFER_INTENT}`,
	plan: `Create or amend terse implementation plans for specs as context requires.
Decompose by observable behavior, not by architectural layer, and order behaviors by delivery value.
Name the modules, interfaces, packages, or classes each behavior touches, without a layer-by-layer build order.
Model the module and interface structure, or the behavior sequence, as a diagram.
Show dependencies between plans and between behaviors visually.
Avoid function and line detail except critical paths.
Do not include real code snippets.
Use terse pseudocode only when necessary.
Use status: draft until approval.
Status: approved requires human approval; later edits to an approved plan require approval again.
${INFER_INTENT}`,
	issue: `Create or amend terse issues as context requires.
Record symptom, impact, reproduction or evidence, and related specs.
Use a sequence diagram for reproduction when the failure crosses components.
Use specs: [] while the violated contract is unknown.
Amend or create specs only when issues expose spec gaps.
${INFER_INTENT}`,
	exec: `Implement the referenced System bundles in thin vertical slices.
Valid exec inputs: spec; spec+plan; optional issue context.
${INFER_INTENT}`,
};

/**
 * Build the user message for one /system stage. The heading shows the stage and
 * the human's own words; the board summary and the stage prompt follow. This
 * message is what the human sees in the transcript and what the agent reads.
 */
export function systemPromptFor(
	subcommand: string,
	instructions: string,
	boardState?: string,
): string {
	const stage = STAGE_PROMPTS[subcommand];
	if (!stage) throw new Error(`Unknown /system subcommand: ${subcommand}`);
	const words = instructions.trim();
	return [
		`# /system ${subcommand}${words ? `: ${words}` : ""}`,
		...(boardState?.trim() ? [boardState.trim()] : []),
		stage,
	].join("\n\n");
}