@mindstudio-ai/remy 0.1.148 → 0.1.149

package/dist/automatedActions/approveInitialPlan.md

@@ -0,0 +1,14 @@
+---
+trigger: approveInitialPlan
+next: buildFromInitialSpec
+---
+
+The user has approved your initial plan. Time to bring it to life.
+
+First, call `setProjectOnboardingState({ state: "building" })` to transition the UI.
+
+Then, write the full spec. Follow the instructions in <spec_authoring_instructions> to write all spec files: app.md, web.md, brand (visual.md, colors.md, typography.md, voice.md), and any others the project needs. Consult the design expert for brand and visual direction. Be thorough: the spec drives everything downstream.
+
+As the final step of spec authoring, call `productVision` to seed the initial roadmap and generate the pitch deck.
+
+When all spec files are written and the roadmap is seeded, end the turn. The build will start automatically.

package/dist/automatedActions/buildFromInitialSpec.md

@@ -3,9 +3,7 @@
   next: postBuildPolish
 ---
 
-This is an automated action triggered by the user pressing "Build" in the editor after reviewing the spec.
-
-The user has reviewed the spec and is ready to build. There are three phases: planning, coding, and verifying. Execute each phase in order in a single turn.
+This is the code generation phase. The spec is written. Build everything now in three phases: planning, coding, and verifying. Execute each phase in order in a single turn.
 
 ## Planning
 Think about your approach and then get a quick sanity check from `codeSanityCheck` to make sure you aren't missing anything. 
@@ -22,3 +20,7 @@ Then, build everything in one turn: tables, methods, interfaces, manifest update
 - If the app has a web frontend, check the browser logs to make sure there are no errors rendering it.
 - Use `runAutomatedBrowserTest` to smoke-test the main UI flow. The dev database is a disposable snapshot, so don't worry about being destructive. Fix any errors before finishing.
 - If there is a scenario that seeds the app with mock data, use it to present the app to the user with initial data seeded, so they can see and play with the real app. Let the user know they can reset the app using a scenario to empty it if they wish. Showing the user something they can play with immediately is important when it comes to landing a strong first impression.
+
+## When you are done
+
+End this turn cleanly once verification passes. Do not finalize or clean up — another chained phase handles that. You are not the last step in the pipeline.

package/dist/automatedActions/buildFromRoadmap.md

@@ -14,3 +14,7 @@ Then, put together a plan to build out the feature. Write the plan with `writePl
 When they've approved the plan, be sure to update the spec first - remember, the spec is the source of truth about the product. Then, build everything in one turn, using the spec as the master plan.
 
 When you're finished building, verify your work and give the user a summary of what was done.
+
+## When you are done
+
+End this turn cleanly once verification passes. Do not finalize or clean up — another chained phase handles that. You are not the last step in the pipeline.

package/dist/automatedActions/postBuildPolish.md

@@ -14,5 +14,5 @@ When you have finished, ask the `visualDesignExpert` to take a screenshot and ve
 ## Finalizing
 When everything is working and polished:
 1. Use `productVision` to mark the MVP roadmap item as done.
-2. Call `setProjectOnboardingState({ state: "onboardingFinished" })`.
-3. Call `compactConversation` to summarize the build session and free up context for the next phase of work.
+2. Call `compactConversation` to summarize the build session and free up context for the next phase of work.
+3. Call `setProjectOnboardingState({ state: "buildComplete" })`. This triggers the reveal experience on the frontend, where the user sees the pitch deck and their finished app for the first time.

package/dist/headless.d.ts

@@ -19,6 +19,95 @@ interface HeadlessOptions {
     model?: string;
     lspUrl?: string;
 }
-declare function startHeadless(opts?: HeadlessOptions): Promise<void>;
+/**
+ * Encapsulates all state and behavior for a headless session. State is
+ * held on instance fields (not closure variables) so mutations are
+ * explicit and greppable. Callbacks passed to external code
+ * (onEvent, onBackgroundComplete, resolveExternalTool, handleStdinLine,
+ * shutdown) are arrow-method fields so `this` is preserved.
+ */
+declare class HeadlessSession {
+    private opts;
+    private config;
+    private state;
+    private sessionStats;
+    private running;
+    private currentAbort;
+    /** RequestId of the in-flight message command — injected into streamed events. */
+    private currentRequestId;
+    /** Guard: track whether terminal `completed` was already sent so we emit exactly one. */
+    private completedEmitted;
+    private turnStart;
+    /**
+     * Onboarding state of the currently-running turn. Captured at runSingleTurn
+     * start so onBackgroundComplete can enqueue background results with the
+     * right state (the triggering turn's state, not a stale one).
+     */
+    private currentOnboardingState;
+    /**
+     * Unified message queue. Holds pending work to deliver after the current
+     * turn completes: chained automated actions, background sub-agent results,
+     * and user messages sent while a turn is running. Strict FIFO. Persisted
+     * to .remy-stats.json so queued work survives process restarts.
+     */
+    private queue;
+    private pendingTools;
+    private earlyResults;
+    private pendingBlockUpdates;
+    private toolRegistry;
+    private readline;
+    constructor(opts?: HeadlessOptions);
+    start(): Promise<void>;
+    private shutdown;
+    private emit;
+    /**
+     * Emit a `completed` event and mark completedEmitted. Includes
+     * `queuedMessages` if the queue has items (sandbox uses this to know the
+     * agent is still busy with pipeline work).
+     */
+    private emitCompleted;
+    /** Returns `{ queuedMessages }` when the queue is non-empty, else empty object. */
+    private queueFields;
+    /** Dispatch a simple (non-streaming) command: call handler, emit response + completed. */
+    private dispatchSimple;
+    /** Persist sessionStats + queue snapshot to .remy-stats.json. */
+    private persistStats;
+    /** Apply queued tool block updates to state.messages. Safe to call any time. */
+    private applyPendingBlockUpdates;
+    /** Drain pending compaction summaries and insert at a safe point. */
+    private applyPendingSummaries;
+    private onBackgroundComplete;
+    private resolveExternalTool;
+    private onEvent;
+    /**
+     * Run one turn (without acquiring the `running` lock). Called by
+     * handleMessage for the initial turn, then repeatedly for each queued
+     * message — `running` stays held across the queue drain so no user
+     * message can slip in mid-pipeline.
+     */
+    private runSingleTurn;
+    private handleMessage;
+    /**
+     * Drain the queue in strict FIFO order. Caller must hold `running = true`.
+     * User messages arriving during the drain will be enqueued behind current items.
+     */
+    private drainQueueLoop;
+    /**
+     * Resume draining the queue when the agent is idle. Acquires the lock,
+     * drains, releases. Used by the `resume` stdin action (sandbox-initiated)
+     * and by kickDrain (background-completion-initiated).
+     */
+    private resumeQueue;
+    /**
+     * Kick off drainage of the queue when the agent is idle. Used by
+     * onBackgroundComplete (when !running) to deliver results without
+     * racing any currently-synchronous path.
+     */
+    private kickDrain;
+    private handleClear;
+    /** Cancel the running turn and drain the queue. Returns the drained items. */
+    private handleCancel;
+    private handleStdinLine;
+}
 
-export { type HeadlessOptions, startHeadless };
+export { type HeadlessOptions, HeadlessSession };