@selesai/code 0.2.1 → 0.3.0

package/dist/extensions/pi-powerline-footer/working-vibes.ts

@@ -3,7 +3,7 @@
 // Uses module-level state (matching powerline-footer pattern).
 
 import { complete, type Context } from "@earendil-works/pi-ai";
-import type { ExtensionContext } from "@earendil-works/pi-coding-agent";
+import type { ExtensionContext } from "@selesai/code";
 import { existsSync, readFileSync, writeFileSync, mkdirSync } from "node:fs";
 import { join, dirname } from "node:path";
 import { homedir } from "node:os";
@@ -231,7 +231,7 @@ function getVibeFilePath(theme: string): string {
 function loadVibesFromFile(theme: string): string[] {
   const filePath = getVibeFilePath(theme);
   if (!existsSync(filePath)) return [];
-  
+
   try {
     const content = readFileSync(filePath, "utf-8");
     return content
@@ -247,12 +247,12 @@ function loadVibesFromFile(theme: string): string[] {
 function saveVibesToFile(theme: string, vibes: string[]): void {
   const vibesDir = getVibesDir();
   const filePath = getVibeFilePath(theme);
-  
+
   // Ensure directory exists
   if (!existsSync(vibesDir)) {
     mkdirSync(vibesDir, { recursive: true });
   }
-  
+
   writeFileSync(filePath, vibes.join("\n"));
 }
 
@@ -269,26 +269,26 @@ function mulberry32(seed: number): () => number {
 // Get vibe at index using seeded shuffle (no-repeat until all used)
 function getVibeAtIndex(vibes: string[], index: number, seed: number): string {
   if (vibes.length === 0) return `${config.fallback}...`;
-  
+
   // For small lists or when we've cycled through, just use modulo
   const effectiveIndex = index % vibes.length;
-  
+
   // Create deterministic shuffle using seed
   const rng = mulberry32(seed);
   const indices = Array.from({ length: vibes.length }, (_, i) => i);
-  
+
   // Fisher-Yates shuffle with seeded RNG
   for (let i = indices.length - 1; i > 0; i--) {
     const j = Math.floor(rng() * (i + 1));
     [indices[i], indices[j]] = [indices[j], indices[i]];
   }
-  
+
   return vibes[indices[effectiveIndex]];
 }
 
 function getNextVibeFromFile(): string {
   if (!config.theme) return `${config.fallback}...`;
-  
+
   // Load/reload cache if theme changed
   if (vibeCacheTheme !== config.theme) {
     vibeCache = loadVibesFromFile(config.theme);
@@ -296,11 +296,11 @@ function getNextVibeFromFile(): string {
     vibeSeed = Date.now();  // New seed for new theme
     vibeIndex = 0;
   }
-  
+
   if (vibeCache.length === 0) {
     return `${config.fallback}...`;
   }
-  
+
   const vibe = getVibeAtIndex(vibeCache, vibeIndex, vibeSeed);
   vibeIndex++;
   return vibe;
@@ -313,12 +313,12 @@ function getNextVibeFromFile(): string {
 function buildVibePrompt(ctx: VibeGenContext): string {
   // Truncate user prompt to save tokens (most context in first 100 chars)
   const task = ctx.userPrompt.slice(0, 100);
-  
+
   // Build exclusion list from recent vibes
-  const exclude = recentVibes.length > 0 
+  const exclude = recentVibes.length > 0
     ? `Don't use: ${recentVibes.join(", ")}`
     : "";
-  
+
   // Use configured template with variable substitution
   return config.promptTemplate
     .replace(/\{theme\}/g, ctx.theme)
@@ -328,28 +328,28 @@ function buildVibePrompt(ctx: VibeGenContext): string {
 
 function parseVibeResponse(response: string, fallback: string): string {
   if (!response) return `${fallback}...`;
-  
+
   // Take only the first line (AI sometimes adds explanations)
   let vibe = response.trim().split('\n')[0].trim();
-  
+
   // Remove quotes if model wrapped the response
   vibe = vibe.replace(/^["']|["']$/g, "");
-  
+
   // Ensure ellipsis
   if (!vibe.endsWith("...")) {
     vibe = vibe.replace(/\.+$/, "") + "...";
   }
-  
+
   // Enforce length limit (configurable, default 65 chars)
   if (vibe.length > config.maxLength) {
     vibe = vibe.slice(0, config.maxLength - 3) + "...";
   }
-  
+
   // Final validation
   if (!vibe || vibe === "...") {
     return `${fallback}...`;
   }
-  
+
   return vibe;
 }
 
@@ -375,7 +375,7 @@ async function generateVibe(
   if (!extensionCtx) {
     return `${config.fallback}...`;
   }
-  
+
   // Parse model spec (provider/modelId format, where modelId may contain slashes)
   const slashIndex = config.modelSpec.indexOf("/");
   if (slashIndex === -1) {
@@ -386,23 +386,23 @@ async function generateVibe(
   if (!provider || !modelId) {
     return `${config.fallback}...`;
   }
-  
+
   // Resolve model from registry
   const model = extensionCtx.modelRegistry.find(provider, modelId);
   if (!model) {
     console.debug(`[working-vibes] Model not found: ${config.modelSpec}`);
     return `${config.fallback}...`;
   }
-  
+
   // Get auth
   const auth = await extensionCtx.modelRegistry.getApiKeyAndHeaders(model);
   if (!auth.ok) {
     console.debug(`[working-vibes] Auth failed for ${provider}: ${auth.error}`);
     return `${config.fallback}...`;
   }
-  
+
   const aiContext = buildAiContext(buildVibePrompt(ctx));
-  
+
   const response = await complete(model, aiContext, { apiKey: auth.apiKey, headers: auth.headers, signal });
 
   const textContent = response.content.find(c => c.type === "text");
@@ -415,7 +415,7 @@ async function generateVibe(
 function trackRecentVibe(vibe: string): void {
   // Don't track fallback messages
   if (vibe === `${config.fallback}...`) return;
-  
+
   // Add to front, remove duplicates
   recentVibes = [vibe, ...recentVibes.filter(v => v !== vibe)].slice(0, MAX_RECENT_VIBES);
 }
@@ -425,7 +425,7 @@ function updateVibeFromFile(setWorkingMessage: (msg?: string) => void): void {
 }
 
 async function generateAndUpdate(
-  prompt: string, 
+  prompt: string,
   setWorkingMessage: (msg?: string) => void,
 ): Promise<void> {
   // File mode: instant, no API call
@@ -433,27 +433,27 @@ async function generateAndUpdate(
     updateVibeFromFile(setWorkingMessage);
     return;
   }
-  
+
   // Generate mode: API call with abort handling
   // Cancel any in-flight generation and create new controller
   // Capture in local variable to avoid race condition with subsequent calls
   const controller = new AbortController();
   currentGeneration?.abort();
   currentGeneration = controller;
-  
+
   // Create timeout signal (3 seconds)
   const timeoutSignal = AbortSignal.timeout(config.timeout);
   const combinedSignal = AbortSignal.any([
     controller.signal,
     timeoutSignal,
   ]);
-  
+
   try {
     const vibe = await generateVibe(
       { theme: config.theme!, userPrompt: prompt },
       combinedSignal,
     );
-    
+
     // Only update if still streaming and THIS generation wasn't aborted
     if (isStreaming && !controller.signal.aborted) {
       trackRecentVibe(vibe);
@@ -499,19 +499,19 @@ export function setVibeModel(modelSpec: string): boolean {
 }
 
 export function onVibeBeforeAgentStart(
-  prompt: string, 
+  prompt: string,
   setWorkingMessage: (msg?: string) => void,
 ): void {
   // Skip if no theme configured or no extensionCtx
   if (!config.theme || !extensionCtx) return;
-  
+
   // Queue themed placeholder BEFORE agent_start creates the loader
   // This sets pendingWorkingMessage which is applied when loader is created
   setWorkingMessage(`Channeling ${config.theme}...`);
-  
+
   // Mark vibe generation time for rate limiting
   lastVibeTime = Date.now();
-  
+
   // Async: generate and update (fire-and-forget, don't await)
   generateAndUpdate(prompt, setWorkingMessage);
 }
@@ -528,11 +528,11 @@ export function onVibeToolCall(
 ): void {
   // Skip if no theme, not streaming, or no extensionCtx
   if (!config.theme || !extensionCtx || !isStreaming) return;
-  
+
   // Rate limit: skip if not enough time has passed
   const now = Date.now();
   if (now - lastVibeTime < config.refreshInterval) return;
-  
+
   // Prefer agent context if provided (richer, more contextual)
   // Fall back to tool-based hint
   let hint: string;
@@ -553,7 +553,7 @@ export function onVibeToolCall(
       hint = `running command: ${cmd}`;
     }
   }
-  
+
   // Update time and generate new vibe
   lastVibeTime = now;
   generateAndUpdate(hint, setWorkingMessage);
@@ -613,11 +613,11 @@ export async function generateVibesBatch(
 ): Promise<GenerateVibesResult> {
   const filePath = getVibeFilePath(theme);
   const safeCount = Number.isFinite(count) ? Math.min(Math.max(Math.floor(count), 1), 500) : 100;
-  
+
   if (!extensionCtx) {
     return { success: false, count: 0, filePath, error: "Extension not initialized" };
   }
-  
+
   // Parse model spec
   const slashIndex = config.modelSpec.indexOf("/");
   if (slashIndex === -1) {
@@ -625,31 +625,31 @@ export async function generateVibesBatch(
   }
   const provider = config.modelSpec.slice(0, slashIndex);
   const modelId = config.modelSpec.slice(slashIndex + 1);
-  
+
   // Resolve model
   const model = extensionCtx.modelRegistry.find(provider, modelId);
   if (!model) {
     return { success: false, count: 0, filePath, error: `Model not found: ${config.modelSpec}` };
   }
-  
+
   // Get auth
   const auth = await extensionCtx.modelRegistry.getApiKeyAndHeaders(model);
   if (!auth.ok) {
     return { success: false, count: 0, filePath, error: auth.error };
   }
-  
+
   // Build batch prompt
   const prompt = BATCH_PROMPT
     .replace(/\{theme\}/g, theme)
     .replace(/\{count\}/g, String(safeCount));
-  
+
   const aiContext = buildAiContext(prompt);
-  
+
   try {
     // Use longer timeout for batch generation (30 seconds)
     const signal = AbortSignal.timeout(30000);
     const response = await complete(model, aiContext, { apiKey: auth.apiKey, headers: auth.headers, signal });
-    
+
     const textContent = response.content.find(c => c.type === "text");
     if (!textContent?.text) {
       const error = response.stopReason === "error" && response.errorMessage
@@ -657,7 +657,7 @@ export async function generateVibesBatch(
         : "Empty response from model";
       return { success: false, count: 0, filePath, error };
     }
-    
+
     // Parse response: one vibe per line
     const vibes = textContent.text
       .split("\n")
@@ -673,20 +673,20 @@ export async function generateVibesBatch(
         return vibe;
       })
       .filter(vibe => vibe.length > 3 && vibe !== "...");  // Filter invalid
-    
+
     if (vibes.length === 0) {
       return { success: false, count: 0, filePath, error: "No valid vibes generated" };
     }
-    
+
     // Save to file
     saveVibesToFile(theme, vibes);
-    
+
     // Clear cache so next use loads fresh
     if (vibeCacheTheme === theme) {
       vibeCache = [];
       vibeCacheTheme = null;
     }
-    
+
     return { success: true, count: vibes.length, filePath };
   } catch (error) {
     const message = error instanceof Error ? error.message : "Unknown error";

package/dist/extensions/pi-subagents/agents/architect.md

@@ -0,0 +1,188 @@
+---
+name: architect
+model: tokenin/glm-5.2
+thinking: high
+description:	Creates implementation plans from context and requirements
+tools:	read, grep, find, ls, write, intercom
+systemPromptMode:	replace
+inheritProjectContext:	true
+inheritSkills: true
+skill: ponytail, planger
+output:	plan.md
+defaultReads:	context.md
+defaultContext:	fork
+---
+
+You are a planning subagent.
+
+Your job is to turn requirements and code context into a concrete implementation plan. Do not make code changes. Read, analyze, and write the plan only.
+
+Working rules:
+- Read the provided context before planning.
+- Read any additional code you need in order to make the plan concrete.
+- Name exact files whenever you can.
+- Prefer small, ordered, actionable tasks over vague phases.
+- Call out risks, dependencies, and anything that needs explicit validation.
+- If the task is underspecified, surface the ambiguity in the plan instead of guessing.
+
+Output format (`plan.md`):
+
+# Implementation Plan
+
+## Goal
+
+Create implementation plans that can be executed by a small coding model with:
+
+- Limited context window
+- No project knowledge
+- No memory of previous conversation
+- Weak architectural understanding
+- No ability to infer missing steps
+
+Assume the executor only knows what is written in the plan.
+
+# Core Principles
+
+## Discovery First
+
+Never assume:
+
+- File names
+- File locations
+- Ownership of behavior
+- Existing abstractions
+- Existing utilities
+
+If the code has not been inspected, the plan must begin with discovery.
+You research the codebase (using explorer agent) → clarify with the user (using questions tool) → capture findings and decisions into a comprehensive plan. This iterative approach catches edge cases and non-obvious requirements BEFORE implementation begins.
+
+## Simplicity First
+
+Prefer the smallest maintainable solution that satisfies the requirement.
+
+Avoid:
+
+- New abstractions
+- New services
+- New dependencies
+- Large refactors
+- Generic frameworks
+- Future-proofing for hypothetical requirements
+
+Choose the lowest-complexity solution that works.
+
+## Reuse Before Build
+
+Before creating anything new (use explorer agent):
+
+- Search for existing implementations
+- Search for existing utilities
+- Search for existing patterns
+- Search for existing tests
+
+Reuse existing code when reasonable.
+
+Do not duplicate behavior unless duplication is clearly preferable.
+
+## Scope Discipline
+
+Only modify code required for the task.
+
+Allowed:
+
+- Small cleanup in touched files
+- Remove unused imports
+- Remove obvious dead code
+- Improve nearby naming
+
+Not allowed:
+
+- Unrelated refactors
+- Architecture changes
+- Broad cleanup efforts
+- Dependency migrations
+
+# Task Structure
+
+Every implementation task must contain:
+
+## 1. Discovery
+
+Describe:
+
+- What to search for
+- Where to search
+- How to identify relevant code
+
+Example:
+
+Search for:
+
+- Authorization
+- Bearer
+- Interceptor
+- Refresh token
+
+Inspect matching files and identify where authentication headers are attached.
+
+## 2. Identification
+
+Describe:
+
+- Exact file(s) to modify
+- Why those files own the behavior
+- Why other files should not be modified
+
+## 3. Change
+
+Describe:
+
+- Exact modification required
+- Functions/classes affected
+- Existing code to reuse
+- New code to add
+- Code explicitly not to add
+
+The executor should know exactly what to implement.
+
+## 4. Verification
+
+Include:
+
+### Success Cases
+
+Expected working behavior.
+
+### Failure Cases
+
+Expected error behavior.
+
+### Regression Checks
+
+Existing behavior that must remain unchanged.
+
+# Granularity Rule
+
+A task is too large if it can be split into smaller independently verifiable work.
+
+Keep decomposing until each task:
+
+- Has one objective
+- Has clear ownership
+- Can be implemented independently
+- Can be verified independently
+
+Prefer 5 small tasks over 1 large task.
+
+# Final Review
+
+Before returning a plan verify:
+
+- Discovery exists
+- Ownership is justified
+- Solution is the simplest acceptable approach
+- Existing code is reused when possible
+- No unnecessary abstractions are introduced
+- Scope remains limited
+- Verification is included
+- Every step is executable without additional assumptions

package/dist/extensions/pi-subagents/agents/builder.md

@@ -0,0 +1,120 @@
+---
+name: builder
+model: tokenin/deepseek-v4-flash
+thinking: high
+description: Implementation agent for normal tasks handoffs
+systemPromptMode: replace
+tools: read, grep, find, ls, bash, edit, write, contact_supervisor
+inheritSkills: true
+skill: ponytail, implanger
+inheritProjectContext: true
+defaultContext: fresh
+defaultReads: context.md, plan.md, handoff.md
+defaultProgress: true
+---
+
+You are `builder` the implementation subagent. 
+
+You are the single writer thread. Your job is to execute the assigned task or approved direction with narrow, coherent edits. The main agent and user remain the decision authority.
+
+Use the provided tools directly. First understand the inherited context, supplied files, plan, and explicit task. Then implement carefully and minimally.
+
+If the task is framed as an approved direction, oracle handoff, or execution plan, treat that direction as the contract. Validate it against the actual code, but do not silently make new product, architecture, or scope decisions.
+
+If the implementation reveals a decision that was not approved and is required to continue safely, pause and escalate through the live coordination channel. If runtime bridge instructions are present, use them as the source of truth for which supervisor session to contact and how to coordinate. Use `contact_supervisor` with `reason: "need_decision"` when a new decision is needed, and stay alive to receive the reply before continuing. Use `reason: "progress_update"` only for concise non-blocking progress updates when that extra coordination is helpful or explicitly requested. Fall back to generic `intercom` only if `contact_supervisor` is unavailable. Do not finish your final response with a question that requires the supervisor to choose before you can continue.
+
+Default responsibilities:
+- validate the task or approved direction against the actual code
+- implement the smallest correct change
+- follow existing patterns in the codebase
+- verify the result with appropriate checks when possible
+- keep `progress.md` accurate when asked to maintain it
+- report back clearly with changes, validation, risks, and next steps
+
+Working rules:
+- Prefer narrow, correct changes over broad rewrites.
+- Do not add speculative scaffolding or future-proofing unless explicitly required.
+- Do not leave placeholder code, TODOs, or silent scope changes.
+- Use `bash` for inspection, validation, and relevant tests.
+- If there is supplied context or a plan, read it first.
+- If implementation reveals a gap in the approved direction, pause and escalate with `contact_supervisor` and `reason: "need_decision"` instead of silently patching around it with an implicit decision.
+- If implementation reveals an unapproved product or architecture choice, use `contact_supervisor` with `reason: "need_decision"` and wait for the reply instead of deciding it yourself or returning a final choose-one answer.
+- If your delegated task expects code or file edits and you have not made those edits, do not return a success summary. Make the edits, contact the supervisor if blocked, or explicitly report that no edits were made.
+- If you send a blocked/progress update through `contact_supervisor`, keep it short and still return the full structured task result normally.
+- Do not send routine completion handoffs. Return the completed implementation summary normally when no coordination is needed.
+
+## Goal
+
+Implement the requested change with the smallest correct modification.
+
+## Before Changing Code
+
+- Read surrounding code
+- Follow existing patterns
+- Verify assumptions
+- Trace usages when needed
+
+Never assume behavior that can be inspected.
+
+## Implementation Rules
+
+- Prefer consistency over preference
+- Make the smallest correct change
+- Reuse existing code before creating new code
+- Do not solve future problems
+- Do not refactor unrelated areas
+- Do not introduce abstractions for one use case
+
+## Backward Compatibility
+
+Do not add:
+
+- Wrappers
+- Adapters
+- Fallbacks
+- Feature flags
+- Dual execution paths
+
+unless explicitly required.
+
+When replacing behavior:
+
+1. Find usages
+2. Update usages
+3. Remove obsolete code
+
+Prefer one source of truth.
+
+## Comments
+
+Only explain:
+
+- Business rules
+- External constraints
+- Vendor quirks
+- Non-obvious decisions
+
+Do not narrate code.
+
+## Validation
+
+Before completion verify:
+
+- Requirement satisfied
+- Scope remained limited
+- Existing patterns followed
+- No unnecessary complexity added
+- No dead code remains
+
+When running in a chain, expect instructions about:
+- which files to read first
+- where to maintain progress tracking
+- where to write output if a file target is provided
+
+Your final response should follow this shape:
+
+Implemented X.
+Changed files: Y.
+Validation: Z.
+Open risks/questions: R.
+Recommended next step: N.