/**
 * Session-end extraction (Phase 2 capture pipeline).
 *
 * The agent does the summarizing — we provide a tight, structured prompt
 * (exposed as an MCP prompt) and a `memory_propose` tool that routes the
 * agent's structured proposals into the human review queue.
 */
export declare const SESSION_END_PROMPT = "You are finishing a coding session. Before you stop, extract durable knowledge about this codebase so future sessions don't have to re-discover it.\n\nReview what you learned this session and propose memories using the `memory_propose` tool. Rules:\n\n1. Only propose things that are DURABLE (true beyond this session) and NON-OBVIOUS (not derivable from a quick file read).\n2. BE SPECIFIC. Every claim must name concrete files, modules, functions, config keys, or commands. Bad: \"The project uses a specific tool for code completion\" (useless). Good: \"The UI is a single-page app generated from src/ui/page.ts which inlines all CSS and JS into one HTML file served by the Express server in src/ui/server.ts\".\n3. REJECT generic statements. If a claim could apply to any repo, discard it. \"Uses TypeScript\" is useless. \"All API handlers in src/api/ must extend BaseHandler and register via src/api/registry.ts\" is useful.\n4. Write each claim as a FALSIFIABLE statement \u2014 something a checker could verify against the code. Bad: \"the auth code is tricky\". Good: \"JWT refresh in src/auth/refresh.ts must run before middleware chain; reordering breaks session renewal (see commit abc123)\".\n5. Pick the right kind:\n   - DECISION: a choice made and why (alternatives rejected)\n   - CONVENTION: a rule consistently followed in this repo\n   - GOTCHA: surprising behavior that cost you time\n   - FAILED_APPROACH: something you tried that did NOT work, and why\n   - ARCHITECTURE: how components fit together\n   - INVARIANT: something that must always/never hold\n   - GUARDRAIL: a behavioral rule for future agents \u2014 pass guardrail_level: 'never' (refuse + explain), 'always' (do without asking), or 'ask-first' (confirm with the user first)\n   - SKILL: a reusable step-by-step procedure (e.g. \"Deploy: 1) \u2026 2) \u2026 3) \u2026\") that the team runs repeatedly\n   - TODO_CONTEXT: unfinished work + the context needed to resume it\n6. Scope each memory to the paths/symbols it applies to. Repo-wide only if truly global.\n7. Attach evidence whenever possible: COMMIT_REF (a sha), STATIC_CHECK (a grep/assertion command that passes iff the claim holds), TEST_RESULT (a test command), or HUMAN_ATTESTED as last resort.\n8. FAILED_APPROACH memories are especially valuable \u2014 they prevent future sessions from repeating dead ends.\n9. Propose 0\u20137 memories. Zero is fine if nothing durable was learned. Do NOT pad.\n10. Before proposing, call `memory_critique` with a short summary of what you did and the files you touched. It checks your work against the project's existing memory and guardrails \u2014 resolve any contradictions or guardrail concerns it raises first.\n11. Separately from YOUR learnings: if the USER stated project facts during this session (\"we use X because Y\", \"never touch Z\", \u2026) that you didn't already capture with `context_note`, call `chat_harvest` once with the user's verbatim messages \u2014 it extracts and queues their statements for review in bulk.\n\nRespect all GUARDRAIL memories you've seen this session: 'never' = refuse and explain why, 'always' = do without asking, 'ask-first' = ask the user before proceeding.\n\nYour proposals enter a human review queue (`dim review`); they do not become active memory until approved.";
/**
 * Ticket-aware variant (TICKETS_DESIGN T5): when the current branch carries a
 * ticket id, teach the agent to pull the ticket's WHY into its proposals —
 * "you fixed the race — should I remember that token refresh must never run
 * concurrently?" The MCP agent is often the better prompting surface.
 */
export declare function sessionEndPromptFor(ticketId: string | null): string;
/** One-line summary of a proposal for human review UIs. */
export declare function proposalSummaryLine(p: {
    id: string;
    kind: string;
    claim: string;
    source: string;
    rationale?: string;
}): string;