bonecode 1.2.3 → 1.4.1

package/dist/src/engine/agent/prompt/title.txt

@@ -0,0 +1,44 @@
+You are a title generator. You output ONLY a thread title. Nothing else.
+
+<task>
+Generate a brief title that would help the user find this conversation later.
+
+Follow all rules in <rules>
+Use the <examples> so you know what a good title looks like.
+Your output must be:
+- A single line
+- ≤50 characters
+- No explanations
+</task>
+
+<rules>
+- you MUST use the same language as the user message you are summarizing
+- Title must be grammatically correct and read naturally - no word salad
+- Never include tool names in the title (e.g. "read tool", "bash tool", "edit tool")
+- Focus on the main topic or question the user needs to retrieve
+- Vary your phrasing - avoid repetitive patterns like always starting with "Analyzing"
+- When a file is mentioned, focus on WHAT the user wants to do WITH the file, not just that they shared it
+- Keep exact: technical terms, numbers, filenames, HTTP codes
+- Remove: the, this, my, a, an
+- Never assume tech stack
+- Never use tools
+- NEVER respond to questions, just generate a title for the conversation
+- The title should NEVER include "summarizing" or "generating" when generating a title
+- DO NOT SAY YOU CANNOT GENERATE A TITLE OR COMPLAIN ABOUT THE INPUT
+- Always output something meaningful, even if the input is minimal.
+- If the user message is short or conversational (e.g. "hello", "lol", "what's up", "hey"):
+  → create a title that reflects the user's tone or intent (such as Greeting, Quick check-in, Light chat, Intro message, etc.)
+</rules>
+
+<examples>
+"debug 500 errors in production" → Debugging production 500 errors
+"refactor user service" → Refactoring user service
+"why is app.js failing" → app.js failure investigation
+"implement rate limiting" → Rate limiting implementation
+"how do I connect postgres to my API" → Postgres API connection
+"best practices for React hooks" → React hooks best practices
+"@src/auth.ts can you add refresh token support" → Auth refresh token support
+"@utils/parser.ts this is broken" → Parser bug fix
+"look at @config.json" → Config review
+"@App.tsx add dark mode toggle" → Dark mode toggle in App
+</examples>

package/dist/src/engine/session/build_mode.d.ts

@@ -0,0 +1,83 @@
+/**
+ * Autonomous Build Mode — small-model-friendly project orchestrator
+ *
+ * Why: small/local models (8-20B) struggle with open-ended "build me X" prompts.
+ * They produce prose, hallucinate edits, and forget what they were doing across
+ * turns. This module replaces the single-turn agent loop with a deterministic
+ * state machine that drives the model through narrow, focused stages.
+ *
+ * State flow:
+ *
+ *   ┌──────────┐     ┌──────────┐     ┌──────────┐     ┌──────────┐
+ *   │ CLARIFY  │ ──▶ │   PLAN   │ ──▶ │ EXECUTE  │ ──▶ │  VERIFY  │
+ *   │ (Q&A)    │     │ (todos)  │     │ (loop)   │     │ (yes/no) │
+ *   └──────────┘     └──────────┘     └─────┬────┘     └─────┬────┘
+ *                                            │                │
+ *                                            ▼                ▼
+ *                                       ┌────────┐       ┌────────┐
+ *                                       │  DONE  │ ◀──── │ all ok │
+ *                                       └────────┘       └────────┘
+ *                                                              │
+ *                                                              │ failures
+ *                                                              ▼
+ *                                                        back to PLAN
+ *
+ * Each stage uses a tightly scoped prompt with a structured-output requirement
+ * (JSON we parse deterministically). The agent's natural "describe what I'd do"
+ * tendency is replaced by short, mechanical answers.
+ *
+ * State is persisted to the sessions table (in build_state JSON column) so
+ * the loop can resume across restarts and is visible to the user via the UI.
+ */
+export type BuildStage = "clarify" | "plan" | "execute" | "verify" | "done" | "failed";
+export interface DesignDoc {
+    goal: string;
+    requirements: string[];
+    constraints: string[];
+    artifacts: string[];
+}
+export interface BuildTodo {
+    id: string;
+    title: string;
+    description: string;
+    status: "pending" | "in_progress" | "completed" | "failed";
+    failure_count: number;
+    evidence?: string;
+}
+export interface BuildState {
+    stage: BuildStage;
+    original_prompt: string;
+    design: DesignDoc | null;
+    todos: BuildTodo[];
+    iteration: number;
+    max_iterations: number;
+    pending_clarification?: string;
+    verification_results?: VerificationResult[];
+    error?: string;
+    /** Set after probe: whether the model can emit OpenAI-format tool calls. */
+    tool_capable?: boolean;
+}
+export interface VerificationResult {
+    requirement: string;
+    satisfied: boolean;
+    evidence: string;
+}
+export interface BuildModeInput {
+    session_id: string;
+    message_id: string;
+    prompt: string;
+    model_id: string;
+    provider_id: string;
+}
+/**
+ * Called when the user has answered the clarification questions.
+ * Combines the original prompt + answers into a finalized design.
+ */
+export declare function continueAfterClarification(session_id: string, user_answer: string, model_id: string, provider_id: string): Promise<BuildState | null>;
+export declare function runBuildMode(input: BuildModeInput): Promise<BuildState>;
+/**
+ * Heuristic: should this prompt go through build mode rather than the
+ * regular agent loop? Build-mode prompts are project-scoped — "build me",
+ * "create a", "design and implement", "make a full" — vs ad-hoc questions.
+ */
+export declare function isBuildPrompt(prompt: string): boolean;