pi-ext

export const DOCUMENT_CONTRACT = `# The System document contract

Use .system bundles only.
The active System root is the nearest .system directory at or above the session cwd; nested systems stay independent and parent systems are never injected.
Authored documents live at .system/<type-plural>/<ID>-<slug>/index.md with lowercase slugs.
Type directories: research, specs, phases, plans, issues.
ID shape: <PREFIX>-<TYPE>-<8 chars from A-Z0-9_->.
Frontmatter refs store IDs only; config schemaVersion is 0.

Required frontmatter:
- research: id, type: research, title
- spec: id, type: spec, title, optional research: string[]
- phase: id, type: phase, title, label
- plan: id, type: plan, title, spec, status: draft|approved, optional depends_on: plan ID[]
- issue: id, type: issue, title, specs: string[]

Research links to no stage; specs may reference research; issues have no status field.
Plan depends_on targets earlier plans for the same spec.
Phases are project-wide operating epochs related to MISSION, not spec decomposition or work breakdown.
Phase labels contain 1-12 ASCII letters, digits, dots, underscores, or hyphens.
Config currentPhase selects the operating phase; changing it requires explicit human confirmation.
Operate only the invoked /system stage; never auto-chain or create bundles for another stage.
Recommend the next stage, then wait for explicit human invocation.
Approved plans are immutable outside an approved /system init bundle migration; otherwise create a new plan bundle.
Mutating existing core files or files in phase and spec bundles requires one-shot human approval.
Keep prose terse, minimal, and essential.
After creating or materially editing a System document, end with:

View:
/system view <ID>
`;

export const MARKDOWN_CONTRACT = `# The System Markdown contract

Use readable Markdown.
Model structure, sequence, state, entities, and decisions visually by default.
Use prose for intent, judgment, and constraints.
When content is a structure, flow, state machine, relation, comparison, or branch, select a format first, then load its matching the-system-* skill.
Mermaid models systems, GFM tables enumerate comparisons, TeX states formal relations, raw HTML mockups show visual or interactive surfaces.
Terse governs prose, not models; a diagram that replaces a paragraph is the terse form.
Keep local Markdown links relative so /system view and /system book can resolve them; use absolute HTTPS links for external sources.
Task lists contain only static checkable criteria and remain unchecked; operational state belongs in .system/board.json.
Never diagram /system stage progression or plan, spec, issue, or board progress.
Replace or remove obsolete canonical text instead of retaining it with strikethrough.
System documents contain no real code snippets; use terse pseudocode only when essential.
`;

export const BOARD_CONTRACT = `# The System board contract

Board state lives only in .system/board.json at schema version 0.
Specs and plans use todo|done; issues use open|done.
A spec may be done without plans, but cannot be done while any linked plan is todo.
Issues never change spec state.
Assessment proposes board changes for human review; it never applies them.
Exec applies verified states directly through system_board_update, recorded with source agent and a terse evidence note.
Claim a state only from verification you ran and read; the human overrides any entry in /system board.
`;

const EXEC_CONTRACT = `# The System exec contract

Implement only what the referenced System bundles require.
Valid exec inputs: spec; spec+plan; optional issue context.
Plan inputs must be status: approved.
The current phase is already project context; do not request or attach it as an exec input.
Load the vertical-slices skill before implementation.
Execute in thin vertical slices of behavior required by the referenced documents.
Referenced documents define required outcome, not implementation order.
Re-sequence layered plan content into vertical slices and implement all of it.
Do not pause for human approval between slices.
Each slice delivers one complete, observable behavior through the system's user-facing or public interface, crossing every layer that behavior requires.
Do not batch work horizontally by architectural layer or component.
Integrate, test, and freshly verify each slice before starting the next; leave the repository working after every slice.
Use tests for nontrivial behavior.
Debug root cause before fixing bugs.
Before claiming implementation complete, run fresh verification and read the full result.
After fresh verification, call system_board_update exactly once with the states your work proves for referenced bundles; use an empty items list when no change is justified.
Each update carries a terse note naming the evidence; a rejected update means the claimed state violates a board invariant.
Final log includes refs, changed areas, verification, and a copyable View block.
Commit messages tell the document-linked story, not file/test inventory.
`;

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.`,
	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.`,
	"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.`,
	assess: `${BOARD_CONTRACT}
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.`,
	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.`,
	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 and makes each plan immutable.`,
	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.`,
	exec: `${BOARD_CONTRACT}
${EXEC_CONTRACT}`,
};

const NEEDS_MARKDOWN = new Set([
	"init",
	"research",
	"spec",
	"spec-verify",
	"phase",
	"plan",
	"issue",
]);

export function systemPromptFor(
	subcommand: string,
	instructions: string,
	boardState?: string,
): string {
	const stage = STAGE_PROMPTS[subcommand];
	if (!stage) throw new Error(`Unknown /system subcommand: ${subcommand}`);
	return [
		DOCUMENT_CONTRACT,
		...(NEEDS_MARKDOWN.has(subcommand) ? [MARKDOWN_CONTRACT] : []),
		`# /system ${subcommand}`,
		stage,
		...(boardState?.trim() ? [boardState.trim()] : []),
		instructions.trim()
			? `# Human instructions\n\n${instructions.trim()}`
			: "# Human instructions\n\nNo instructions were supplied. Infer intent with focused questions or selection before writing.",
	].join("\n\n");
}