@frenchtoastman/oh-my-groundcontrol 0.0.8 → 0.0.12

package/README.md

@@ -44,7 +44,7 @@ Install and configure by following the instructions here:
 https://raw.githubusercontent.com/frenchtoasters/oh-my-groundcontrol/refs/heads/master/README.md
 ```
 
-**Detailed installation guide:** [docs/installation.md](docs/installation.md)
+**Note:** We recommend adding `.groundcontrol/` to your project's `.gitignore` to prevent generated flight plans from being committed.
 
 **Additional guides:**
 - **[Antigravity Setup](docs/antigravity.md)** - Complete guide for Antigravity provider configuration  
@@ -83,30 +83,10 @@ The principles driving our agent behavior are extracted directly from the [NASA
 
 *Those who plan, perceive, and verify before the launch sequence begins.*
 
-```mermaid
-graph TD
-    U["🧑 User"] -->|"request"| P["🏛️ Groundcontrol"]
-    P -->|"gap analysis"| S["👁️ PreFlight"]
-    P -->|"codebase recon"| E["🧭 Explorer"]
-    P -->|"knowledge retrieval"| L["📜 Librarian"]
-    P -->|"plan verification"| M["⚖️ Verification"]
-    S -.->|"risks & gaps"| P
-    E -.->|"file map"| P
-    L -.->|"docs & references"| P
-    M -.->|"PASS / FAIL"| P
-    P -->|"approved plan"| O["👑 Orchestrator"]
-
-    style P fill:#2d4a22,stroke:#4a7c34,color:#fff
-    style S fill:#4a3728,stroke:#7a5a3e,color:#fff
-    style E fill:#1a3a4a,stroke:#2a6a8a,color:#fff
-    style L fill:#3a2a4a,stroke:#6a4a8a,color:#fff
-    style M fill:#4a4a1a,stroke:#8a8a2a,color:#fff
-    style O fill:#4a2a1a,stroke:#8a4a2a,color:#fff
-```
 
 ---
 
-### 01. Contractor: The Lead Systems Engineer
+### 01. Groundcontrol: The Lead Systems Engineer
 
 <table>
   <tr>
@@ -114,7 +94,7 @@ graph TD
       <sub><i>Designs the mission architecture.</i></sub>
     </td>
     <td width="70%" valign="top">
-      Operating from the engineering drafting boards, the Contractor shapes the mission blueprint before a single line of code is written. They conduct rigorous requirements gathering, consult on system constraints, and deliver decision-complete schematics to ensure the objective is achievable. No system is built without their approved plan.
+      Operating from the engineering drafting boards, Groundcontrol shapes the mission blueprint before a single line of code is written. They conduct rigorous requirements gathering, consult on system constraints, and deliver decision-complete schematics to ensure the objective is achievable. No system is built without their approved plan.
     </td>
   </tr>
   <tr>
@@ -124,7 +104,7 @@ graph TD
   </tr>
   <tr>
     <td colspan="2">
-      <b>Prompt:</b> <a href="src/agents/contractor/index.ts"><code>contractor/index.ts</code></a>
+      <b>Prompt:</b> <a href="src/agents/groundcontrol/index.ts"><code>contractor/index.ts</code></a>
     </td>
   </tr>
   <tr>
@@ -136,7 +116,7 @@ graph TD
 
 ---
 
-### 03. PreFlight: The Risk Analyst
+### 02. PreFlight: The Risk Analyst
 
 <table>
   <tr>
@@ -166,7 +146,7 @@ graph TD
 
 ---
 
-### 04. Verification: The Launch Committer
+### 03. Verification: The Launch Committer
 
 <table>
   <tr>
@@ -200,29 +180,10 @@ graph TD
 
 *Those who explore, advise, and execute once the plan is authorized.*
 
-```mermaid
-graph TD
-    P["🏛️ Groundcontrol"] -->|"approved plan"| O["👑 Orchestrator"]
-    O -->|"implementation"| F["⚒️ Fixer"]
-    O -->|"UI/UX"| D["🎨 Designer"]
-    O -->|"codebase recon"| E["🧭 Explorer"]
-    O -->|"architecture advice"| R["🔮 Oracle"]
-    F -.->|"code changes"| O
-    D -.->|"visual polish"| O
-    E -.->|"file map"| O
-    R -.->|"guidance"| O
-
-    style O fill:#4a2a1a,stroke:#8a4a2a,color:#fff
-    style F fill:#3a3a3a,stroke:#6a6a6a,color:#fff
-    style D fill:#4a1a3a,stroke:#8a2a6a,color:#fff
-    style E fill:#1a3a4a,stroke:#2a6a8a,color:#fff
-    style R fill:#2a2a4a,stroke:#4a4a8a,color:#fff
-    style P fill:#2d4a22,stroke:#4a7c34,color:#fff
-```
 
 ---
 
-### 05. Orchestrator: The Flight Director
+### 04. Orchestrator: The Flight Director
 
 <table>
   <tr>
@@ -252,7 +213,7 @@ graph TD
 
 ---
 
-### 06. Explorer: The Telemetry Scout
+### 05. Explorer: The Telemetry Scout
 
 <table>
   <tr>
@@ -282,7 +243,7 @@ graph TD
 
 ---
 
-### 07. Oracle: The Principal Architect
+### 06. Oracle: The Principal Architect
 
 <table>
   <tr>
@@ -312,7 +273,7 @@ graph TD
 
 ---
 
-### 08. Librarian: The Data Archivist
+### 07. Librarian: The Data Archivist
 
 <table>
   <tr>
@@ -342,7 +303,7 @@ graph TD
 
 ---
 
-### 09. Designer: The Interface Specialist
+### 08. Designer: The Interface Specialist
 
 <table>
   <tr>
@@ -372,7 +333,7 @@ graph TD
 
 ---
 
-### 10. Fixer: The Systems Integrator
+### 09. Fixer: The Systems Integrator
 
 <table>
   <tr>

package/dist/agents/groundcontrol/system-prompt.d.ts

@@ -9,8 +9,11 @@ export declare const GROUNDCONTROL_SYSTEM_PROMPT = "<system-reminder>\n# Groundc
  * Question permission allows agent to ask user questions.
  */
 export declare const GROUNDCONTROL_PERMISSION: {
-    edit: "allow";
-    bash: "allow";
+    edit: {
+        '.groundcontrol/**/*': "allow";
+        '*': "ask";
+    };
+    bash: "ask";
     webfetch: "allow";
     question: "allow";
 };

package/dist/index.js

@@ -20820,8 +20820,11 @@ ${GROUNDCONTROL_HIGH_ACCURACY_MODE}
 ${GROUNDCONTROL_PLAN_TEMPLATE}
 ${GROUNDCONTROL_BEHAVIORAL_SUMMARY}`;
 var GROUNDCONTROL_PERMISSION = {
-  edit: "allow",
-  bash: "allow",
+  edit: {
+    ".groundcontrol/**/*": "allow",
+    "*": "ask"
+  },
+  bash: "ask",
   webfetch: "allow",
   question: "allow"
 };
@@ -20933,6 +20936,11 @@ var ORACLE_PROMPT = `You are Oracle - a strategic technical advisor.
 - Focus on strategy, not execution
 - Point to specific files/lines when relevant
 
+**Root Cause Analysis (5 Whys)**:
+- When investigating complex, recurring, or systemic bugs, explicitly execute a formal "5 Whys" Root Cause Analysis.
+- Present this as a numbered list, drilling down 5 layers past the symptom to identify the core architectural or process failure.
+- *Early Exit*: Do not use 5 Whys for simple syntax errors, obvious typos, or known external service outages.
+
 **NASA Guardrails (High-Reliability Mode)**:
 - **Destructive Pause**: Stop and request explicit user confirmation before irreversible actions (e.g., force pushing, bulk deletions).
 - **Pre-Flight Verification**: Always run linters/typechecks (\`bun run check:ci\`, \`bun run typecheck\`) to validate changes before concluding.
@@ -21434,6 +21442,15 @@ Architecture | Research]
 
 ---
 
+## INTERNAL REASONING: INVISIBLE 5 WHYS
+
+When gathering requirements or defining scope, adopt a "5 Whys" mindset to uncover the root intent behind a user's request (e.g., if they ask for a caching layer, determine if the root issue is an N+1 query).
+- **MUST**: Use internal Chain-of-Thought (or careful lateral questioning) to drill down up to 5 layers deep to find the true requirement.
+- **MUST NOT**: Literally ask the user "Why?" repeatedly. Do not badger the user.
+- **EXIT STRATEGY**: If the root cause is obvious, or if the user explicitly demands immediate execution ("just build it"), abort the probing and proceed with current context.
+
+---
+
 ## CRITICAL RULES
 
 **NEVER**:
@@ -21553,6 +21570,11 @@ is enough.
 **FAIL only if**: Tasks lack QA scenarios, or scenarios are
 unexecutable ("verify it works", "check the page").
 
+### 5. Assumption Stress-Testing (Invisible 5 Whys)
+- Internally use a "5 Whys" approach to stress-test the plan's assumptions (e.g., "Why will this step succeed? Because the API is available. Why is it available?").
+- Use this strictly as an internal mental model to identify fragile logical leaps.
+- Do not output the 5 Whys in your response. Only flag a BLOCKER if the assumption fails critically.
+
 ---
 
 ## What You Do NOT Check
@@ -21716,6 +21738,8 @@ need figuring out. Fail only if zero context.
 **Critical blockers**: Missing info that would completely stop work,
 or contradictions. Minor ambiguities are NOT blockers.
 
+**Assumption stress-testing (Invisible 5 Whys)**: Internally use a 5 Whys approach to stress-test plan assumptions. Do not output the 5 Whys. Only flag if an assumption fails critically.
+
 **QA scenario executability**: Does each task have QA scenarios with
 tool + steps + expected results? Missing or vague QA scenarios are
 blockers.
@@ -23140,13 +23164,13 @@ function createAutoUpdateCheckerHook(ctx, options = {}) {
         const displayVersion = localDevVersion ?? cachedVersion;
         if (localDevVersion) {
           if (showStartupToast) {
-            showToast(ctx, `OMO-Slim ${displayVersion} (dev)`, "Running in local development mode.", "info");
+            showToast(ctx, `OMO-Groundcontrol ${displayVersion} (dev)`, "Running in local development mode.", "info");
           }
           log("[auto-update-checker] Local development mode");
           return;
         }
         if (showStartupToast) {
-          showToast(ctx, `OMO-Slim ${displayVersion ?? "unknown"}`, "oh-my-groundcontrol is active.", "info");
+          showToast(ctx, `OMO-Groundcontrol ${displayVersion ?? "unknown"}`, "oh-my-groundcontrol is active.", "info");
         }
         runBackgroundUpdateCheck(ctx, autoUpdate).catch((err) => {
           log("[auto-update-checker] Background update check failed:", err);
@@ -23179,14 +23203,14 @@ async function runBackgroundUpdateCheck(ctx, autoUpdate) {
   }
   log(`[auto-update-checker] Update available (${channel}): ${currentVersion} \u2192 ${latestVersion}`);
   if (!autoUpdate) {
-    showToast(ctx, `OMO-Slim ${latestVersion}`, `v${latestVersion} available. Restart to apply.`, "info", 8000);
+    showToast(ctx, `OMO-Groundcontrol ${latestVersion}`, `v${latestVersion} available. Restart to apply.`, "info", 8000);
     log("[auto-update-checker] Auto-update disabled, notification only");
     return;
   }
   if (pluginInfo.isPinned) {
     const updated = updatePinnedVersion(pluginInfo.configPath, pluginInfo.entry, latestVersion);
     if (!updated) {
-      showToast(ctx, `OMO-Slim ${latestVersion}`, `v${latestVersion} available. Restart to apply.`, "info", 8000);
+      showToast(ctx, `OMO-Groundcontrol ${latestVersion}`, `v${latestVersion} available. Restart to apply.`, "info", 8000);
       log("[auto-update-checker] Failed to update pinned version in config");
       return;
     }
@@ -23195,11 +23219,11 @@ async function runBackgroundUpdateCheck(ctx, autoUpdate) {
   invalidatePackage(PACKAGE_NAME);
   const installSuccess = await runBunInstallSafe(ctx);
   if (installSuccess) {
-    showToast(ctx, "OMO-Slim Updated!", `v${currentVersion} \u2192 v${latestVersion}
+    showToast(ctx, "OMO-Groundcontrol Updated!", `v${currentVersion} \u2192 v${latestVersion}
 Restart OpenCode to apply.`, "success", 8000);
     log(`[auto-update-checker] Update installed: ${currentVersion} \u2192 ${latestVersion}`);
   } else {
-    showToast(ctx, `OMO-Slim ${latestVersion}`, `v${latestVersion} available. Restart to apply.`, "info", 8000);
+    showToast(ctx, `OMO-Groundcontrol ${latestVersion}`, `v${latestVersion} available. Restart to apply.`, "info", 8000);
     log("[auto-update-checker] bun install failed; update not installed");
   }
 }

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@frenchtoastman/oh-my-groundcontrol",
-  "version": "0.0.8",
-  "description": "Lightweight agent orchestration plugin for OpenCode - a slimmed-down fork of oh-my-opencode",
+  "version": "0.0.12",
+  "description": "An OpenCode plugin for multi-agent orchestration for structured planning with NASA-style guardrails.",
   "main": "dist/index.js",
   "types": "dist/index.d.ts",
   "bin": {