@hybridlabor-api/aos 4.9.0 → 4.10.0

package/skills/global_config/plan-canvas/SKILL.md

@@ -3,7 +3,7 @@ name: plan-canvas
 description: Open plans and HTML artifacts in a local browser canvas where the human annotates elements, chats, and approves or requests changes without leaving the page. Use when presenting a plan for review, or when feedback like "move this, change that" is easier pointed at than typed.
 category: bdb-core
 metadata:
-  version: "1.0.0"
+  version: "1.0.1"
   origin: affaan-m/ECC
   license: MIT
 ---
@@ -28,6 +28,10 @@ AOS from [affaan-m/ECC](https://github.com/affaan-m/ECC).
   decision — the canvas verdict replaces a typed "yes/proceed".
 - **Mandatory, not optional**, at the end of `bdbrainstorm` (before writing
   `state.goal` / handing off to `/startcycle-graph`) and `bdbmediastorm`
+- **Visual Extensions (BuilderIO Integration):** When generating plans, always ask the human which Canvas version they prefer:
+  - **Plan-Canvas Preview**: Standard markdown/html review.
+  - **Archify Canvas**: For strict architecture schema validation.
+  - **Visual Ecosystem**: Use `/visual-plan` (turn text plans into rich visual plans), `/visual-recap` (turn diffs into interactive visual recaps), or `/visual-edit` (open a running local app for visual editing).
   (before the show-control architecture is considered final) — both produce
   a plan/spec artifact a human must approve before anything downstream
   proceeds. See each skill's own "Plan Canvas Review" section.
@@ -75,11 +79,14 @@ If your turn ends with nothing listening, the message sits in the queue and,
 from the human's side of the glass, sending appears to do nothing at all.
 
 So **run `await` as a background task** when your harness supports one (in
-Claude Code, a Bash call with `run_in_background: true`). It exits the moment
+Claude Code, a Bash call with `run_in_background: true`; in Antigravity, use `WaitMsBeforeAsync: 500`). It exits the moment
 feedback arrives and the harness hands you the JSON, which keeps the loop alive
 across turns instead of dying with the foreground call. A foreground `await`
 works too, but only until the harness time-limits it.
 
+> **OpenCode Limitations**: OpenCode currently lacks reactive background tasks (like AGY's `WaitMsBeforeAsync`) or background shells. If you are running in OpenCode, you must poll explicitly if needed (e.g., `aos-plan-canvas await <file> --timeout-ms 10000`), or launch the opencode-subagent to handle the waiting. 
+> Furthermore, OpenCode's execution environment often fails to launch the default browser automatically. **Whenever you use `open` or `await`, ALWAYS print the direct Canvas URL to the user in chat (e.g., "🔗 Canvas geöffnet: http://127.0.0.1:4519/canvas/...")** so they can click it manually.
+
 One backstop exists, and it is not an excuse to skip the above:
 
 - `aos-plan-canvas pending` lists feedback queued with no listener. Check it

package/skills/global_config/plan-canvas/scripts/lib/plan-canvas/ui.js

@@ -544,7 +544,11 @@ function renderMarkdownArtifactHtml(bodyHtml, { title, sdkSrc }) {
 ${TOKENS_CSS}
   *{margin:0;padding:0;box-sizing:border-box}
   body{font-family:var(--font);background:var(--bg);color:var(--text);-webkit-font-smoothing:antialiased;line-height:1.65;font-size:14.5px}
-  .doc{max-width:860px;margin:0 auto;padding:44px 36px 90px}
+  /* Two tracks: tables, code and diagrams take the whole frame; prose keeps a
+     readable measure. A single narrow column starved wide tables, and a single
+     wide column made body text unreadable. */
+  .doc{max-width:min(1560px,100%);margin:0 auto;padding:44px 36px 90px}
+  .doc>p,.doc>ul,.doc>ol,.doc>blockquote{max-width:104ch}
   h1,h2,h3,h4,h5,h6{line-height:1.25;margin:1.6em 0 .55em;letter-spacing:-.01em}
   h1{font-size:26px;margin-top:.3em;padding-bottom:.45em;border-bottom:1px solid var(--border)}
   h1:after{content:'';display:block;width:56px;height:3px;margin-top:14px;border-radius:2px;background:linear-gradient(90deg,var(--accent),var(--pink))}
@@ -563,7 +567,11 @@ ${TOKENS_CSS}
   pre code{background:none;border:none;padding:0;font-size:12.5px;line-height:1.55}
   blockquote{border-left:3px solid var(--accent);background:var(--accent-glow);border-radius:0 var(--radius-sm) var(--radius-sm) 0;padding:8px 14px;color:var(--text2)}
   table{width:100%;border-collapse:collapse;font-size:13px;display:block;overflow-x:auto}
-  th,td{text-align:left;padding:7px 12px;border:1px solid var(--border)}
+  /* a clipped column must look scrollable, not truncated: keep the scrollbar visible */
+  table::-webkit-scrollbar{height:9px}
+  table::-webkit-scrollbar-thumb{background:var(--border-light);border-radius:99px}
+  table::-webkit-scrollbar-track{background:var(--bg3);border-radius:99px}
+  th,td{text-align:left;padding:7px 10px;border:1px solid var(--border)}
   th{background:var(--bg3);font-weight:600;font-size:11.5px;text-transform:uppercase;letter-spacing:.04em;color:var(--text2);white-space:nowrap}
   tbody tr:hover{background:var(--surface-hover)}
   hr{border:none;border-top:1px solid var(--border);margin:1.6em 0}

package/skills/global_config/plan-canvas/scripts/plan-canvas.js

@@ -37,7 +37,7 @@ const {
   resolvePort
 } = require('./lib/plan-canvas/server');
 
-const VERSION = '1.0.0';   // vendored Plan Canvas protocol version; matches SKILL.md metadata.version.
+const VERSION = '1.0.1';   // vendored Plan Canvas protocol version; matches SKILL.md metadata.version.
                            // Bump when the vendored JS changes, to force a stale detached server to restart.
 
 const SAFE_REQUEST_PATHS = new Set([

package/skills/global_config/read-the-damn-docs/SKILL.md

@@ -0,0 +1,175 @@
+---
+name: read-the-damn-docs
+description: >-
+  Use when implementing, integrating, upgrading, debugging, or answering
+  anything involving third-party APIs, libraries, frameworks, CLIs, cloud
+  services, model or provider SDKs, fast-moving product behavior, unfamiliar
+  repo docs or specs, errors that may indicate API drift, or high-stakes auth,
+  security, billing, data, migration, deployment, compliance, or privacy
+  behavior. Forces a docs pass before coding from memory.
+category: engineering-method
+source: BuilderIO/skills
+---
+
+# Read The Damn Docs
+
+Do not guess where authoritative docs can answer the question. The most common
+correct move is to search for the current official docs, open the relevant
+pages, and read them before writing code. For APIs, versions, provider behavior,
+config, limits, lifecycle hooks, or security-sensitive flows, ground the answer
+in what the docs actually say.
+
+**Division of labour with `AGENTS.md`.** `AGENTS.md`'s *Zero guesswork* rule
+states the obligation and the trigger list. This skill is the **procedure** that
+discharges it. If the two ever disagree, the rule in `AGENTS.md` wins and this
+file is the thing that should change.
+
+Adapted from [BuilderIO/skills](https://github.com/BuilderIO/skills) (MIT).
+Prose only — no upstream scripts, no agent config, no dependency.
+
+---
+
+## 1. Docs-First Triggers
+
+Read docs before proceeding when any of these are true:
+
+- The user asks for "latest", "current", "official", "supported", "best
+  practice", "recommended", "today", "now", or "look it up".
+- The needed docs are **not** already in the repo or supplied by the user.
+  Search for the official docs rather than hoping model memory is current.
+- The task adds, upgrades, configures, or imports a package, SDK, framework,
+  plugin, CLI, model, cloud resource, or provider integration.
+- The API is fast-moving or version-sensitive: AI SDKs, model provider APIs,
+  Next.js, React, Tailwind, Vite, Drizzle, Prisma, Stripe, GitHub, Slack,
+  Notion, browser APIs, deployment platforms, auth libraries, and similar.
+- The implementation depends on auth, OAuth scopes, permissions, secrets,
+  webhooks, billing, payments, PII, encryption, data retention, migrations,
+  retries, rate limits, quotas, caching, deploys, or compliance.
+- An error mentions deprecation, unknown options, missing exports, invalid
+  config, unsupported fields, changed defaults, or version mismatch.
+- The repo has local docs, ADRs, generated schemas, OpenAPI specs, route or
+  action registries, design-system docs, or package-level READMEs that could
+  define the contract.
+- The choice is expensive to reverse: public wire formats, database schema,
+  migration strategy, persistent IDs, event names, customer-visible behavior,
+  or external automation contracts.
+- You catch yourself about to write "usually", "probably", "I think", "from
+  memory", or code copied from model memory for an external API.
+
+---
+
+## 2. What Counts As Docs
+
+Use the most authoritative source available:
+
+- **Local** repo docs, specs, ADRs, schemas, generated types, package READMEs,
+  and tests — for project-specific behaviour.
+- **Official** product docs, API references, migration guides, changelogs,
+  release notes, and SDK source or type definitions — for third-party
+  behaviour. Find these with web search when you do not already have the URL.
+- **Package registry metadata** for versions. Before adding a dependency, check
+  its current version (`npm view <pkg> version`, `pnpm view <pkg> version`, or
+  the ecosystem equivalent), then read the docs for *that* major version.
+- **Source code or type definitions** when official docs are incomplete. Treat
+  this as evidence, not folklore.
+
+Avoid Stack Overflow, old blog posts, random snippets, and memory as the
+primary source when official docs exist. Use community sources only to debug
+symptoms *after* the authoritative contract is known.
+
+**In this environment:** `firecrawl-search` and `firecrawl-scrape` are the
+installed tools for the web pass, and `deja-memory` / `memb_mcp` can surface
+prior project knowledge. Neither substitutes for a docs read.
+
+---
+
+## 3. Required Workflow
+
+1. **Identify the exact surface** — package name, installed version, target
+   version, provider endpoint, CLI command, config file, local helper, schema,
+   or product feature.
+2. **Search for the current official docs**, unless the relevant docs are
+   already local or the user supplied a URL. Targeted queries work best:
+   `<product> <feature> official docs`, `<package> migration guide`,
+   `<provider> API reference`.
+3. **Open and read the docs closest to that surface.** Prefer local docs first
+   for internal code, then official upstream docs. For new packages, verify the
+   latest version before writing imports, config, or install commands.
+4. **Extract the few facts needed** — option names, imports, lifecycle rules,
+   default behaviour, breaking changes, limits, permissions, and examples for
+   the current major version.
+5. **Implement or answer using those facts.** If the docs conflict with existing
+   code, inspect the local code path and call out the discrepancy — do not
+   silently pick one.
+6. **Verify with the smallest useful check** — typecheck, tests, build, CLI dry
+   run, API schema validation, or a local reproduction. This is the same
+   "narrowest quiet validation" rule the Shipping gate enforces.
+7. **Name what you read** in the final answer, when that evidence affected the
+   recommendation or the implementation.
+
+---
+
+## 4. Examples That Must Trigger A Docs Pass
+
+- *"Add Tailwind to this app."* — Check the current Tailwind major and its
+  install docs before creating config files or assuming old PostCSS setup.
+- *"Stream responses with the AI SDK."* — Verify the current SDK major,
+  provider package names, streaming helpers, and runtime examples.
+- *"Wire up Stripe webhooks."* — Read current signature verification, event
+  retry, endpoint secret, and framework body-parsing docs before coding.
+- *"Fix this Next.js caching bug."* — Read the docs for the **installed** major
+  and router mode before assuming cache invalidation semantics.
+- *"Add Drizzle migrations."* — Read the current kit docs **and** the existing
+  repo migration conventions before generating files.
+- *"Create a GitHub Action."* — Read Actions syntax and permissions docs,
+  especially `pull_request`, `workflow_run`, OIDC, tokens, and artifacts.
+- *"Why does this OAuth flow fail?"* — Read the provider's scopes, redirect URI,
+  PKCE, token refresh, and app-verification docs before changing code.
+- *"Use this repo's plan/comment/action system."* — Read local docs, route and
+  action registries, schemas, and tests before inventing endpoints or props.
+- *"Upgrade Vite/React."* — Read the migration guide for the **exact** target
+  major before editing config or imports.
+- *"What model should we use?"* — Read current provider model docs, pricing and
+  limits pages, and SDK examples before recommending.
+
+---
+
+## 5. When A Quick Local Read Is Enough
+
+Do not search the web for every tiny edit. A docs pass can be local and brief
+when the answer is already in the repo: existing helper usage, nearby tests,
+typed interfaces, generated clients, ADRs, or package READMEs.
+
+But if the task depends on an external tool, package, provider, or current
+product behaviour, a search is usually the right first step. For trivial
+language syntax, typo fixes, formatting, or self-contained code with no
+external contract, proceed normally.
+
+---
+
+## 6. If Docs Are Unavailable
+
+If network access, auth, or missing local files prevents reading the docs, say
+that plainly **before** relying on memory. Narrow the uncertainty, inspect
+source or types if available, and do not present the result as
+confirmed-current. A clearly-labelled estimate is useful; an unlabelled one is
+a defect.
+
+---
+
+## 7. Verification
+
+- [ ] Every trigger in §1 was checked before writing code, not after.
+- [ ] The exact version in play was established (installed vs. target), and the
+      docs read match that major.
+- [ ] At least one authoritative source backs every external API, option name,
+      default, limit, and lifecycle claim in the output.
+- [ ] No claim rests on Stack Overflow, a blog post, or model memory as its
+      primary source.
+- [ ] Conflicts between docs and local code were surfaced, not silently
+      resolved.
+- [ ] The smallest useful verification check was run and its result reported.
+- [ ] The sources consulted are named in the response where they affected the
+      recommendation.
+- [ ] Any remaining uncertainty is stated explicitly, with what would resolve it.
+- [ ] No npm dependency, script, or executable was added by this skill.

package/skills/global_config/writing-plans/SKILL.md

@@ -182,24 +182,24 @@ If you find issues, fix them inline. No need to re-review — just fix and move
 
 ## Execution Handoff
 
-After saving and self-reviewing the plan, link it for your human partner
-to read. If they have already explicitly supplied an execution method, ask
-them to review the plan and confirm it captures what they want; wait for that
-review before implementation, then use the preserved method. Otherwise, ask
-them to review the plan and choose an execution method before implementation.
+After saving and self-reviewing the plan, you **MUST** open it in the Plan Canvas for the user to review. Do not ask them to read the markdown file in the terminal.
 
-**When no execution method has already been supplied:**
+1. **Render Architecture:** If the plan contains complex flows, render them using `aos-archify` (see `archify` skill).
+2. **Open Canvas:** Run `aos-plan-canvas open docs/plans/<filename>.md` (or `.html` if using archify).
+3. **Await Feedback:** Run `aos-plan-canvas await docs/plans/<filename>.md` as a background task. 
 
-**"Plan complete and saved to `docs/plans/<filename>.md`. Please review the plan. Which execution approach would you prefer?**
+Tell the user:
+**"Plan complete and saved! Ich habe den Plan im Canvas für dich geöffnet. Bitte schau ihn dir im Browser an und gib mir dort dein Feedback oder klicke auf Approve."**
 
-- **Subagent-driven** - A fresh subagent implements each task and a fresh reviewer checks it before the next one starts, then a whole-branch review at the end. Most thorough; costs a fresh context per task and per review.
-- **Native** - I implement every task myself in this session, the way this harness runs work, then one fresh reviewer on the most capable model checks the whole branch. Cheapest and fastest; no independent review until the end. Runs well with a mid-tier session model, since the plan carries the design.
+*(If running in OpenCode, always explicitly print the Canvas URL in chat so the user can click it).*
 
-**For this plan I recommend <one of the two>, because <one sentence from the plan: how much the tasks depend on each other's interfaces, how many there are, what a shipped mistake would cost>. Does the plan capture what you want, and which approach should we use?"**
+Wait for the `approve` verdict from the Canvas before proceeding to execution.
 
-**When an execution method has already been supplied:**
+**When the plan is approved, ask for the execution method (if not already supplied):**
 
-**"Plan complete and saved to `docs/plans/<filename>.md`. Please review the plan. Does it capture what you want?"**
+**"Welchen Ausführungsansatz sollen wir wählen?**
+- **Subagent-driven** - Ein frischer Subagent für jede Aufgabe. (Am gründlichsten, aber teurer).
+- **Native** - Ich implementiere alle Tasks selbst nacheinander in dieser Session. (Schneller, günstiger)."
 
 **If Subagent-driven chosen:**
 - **REQUIRED SUB-SKILL:** Use subagent-driven-development

package/skills/global_config/writing-plans-legacy/SKILL.md

@@ -111,9 +111,22 @@ git commit -m "feat: add specific feature"
 
 ## Execution Handoff
 
-After saving the plan, offer execution choice:
+After saving the plan, you **MUST** open it in the Plan Canvas for the user to review. Do not ask them to read the markdown file in the terminal.
 
-**"Plan complete and saved to `docs/plans/<filename>.md`. Two execution options:**
+1. **Render Architecture:** If the plan contains complex flows, render them using `aos-archify` (see `archify` skill).
+2. **Open Canvas:** Run `aos-plan-canvas open docs/plans/<filename>.md` (or `.html` if using archify).
+3. **Await Feedback:** Run `aos-plan-canvas await docs/plans/<filename>.md` as a background task. 
+
+Tell the user:
+**"Plan complete and saved! Ich habe den Plan im Canvas für dich geöffnet. Bitte schau ihn dir im Browser an und gib mir dort dein Feedback oder klicke auf Approve."**
+
+*(If running in OpenCode, always explicitly print the Canvas URL in chat so the user can click it).*
+
+Wait for the `approve` verdict from the Canvas before proceeding to execution.
+
+**When the plan is approved, offer execution choice:**
+
+**"Plan is approved. Two execution options:**
 
 **1. Subagent-Driven (this session)** - I dispatch fresh subagent per task, review between tasks, fast iteration
 

package/.claude/CLAUDE.md

@@ -1,12 +0,0 @@
-<!-- memB-start -->
-# memB Auto-Injected Context
-The following knowledge was automatically retrieved from the memB vector engine.
-
-## Global Developer Preferences (Godmode)
-
-## Project Context: bdb-dev-optimized-agent-skills
-- None
-- None
-- None
-- None
-<!-- memB-end -->

package/mcps/RhinoMCP/docs/content/docs/getting-started/gemini.md

@@ -1,61 +0,0 @@
----
-title: Gemini CLI
-icon: gemini
-weight: 6
-prev: docs/getting-started
-next: docs/try-it-out
-toc: false
-author: SteveF
-keywords:
-  - Gemini CLI
-  - Google
-  - terminal
-  - CLI
----
-
-[Gemini CLI](https://github.com/google-gemini/gemini-cli) is Google's open-source terminal AI assistant. It speaks MCP, so once you point it at the Rhino MCP server it can drive Rhino & Grasshopper the same way Claude or Codex can.
-
-If you're choosing between assistants and aren't sure, start with [Claude Desktop](../connector); it's the gentler entry point.
-
-## 1. Install Gemini CLI
-
-[Gemini CLI](https://github.com/google-gemini/gemini-cli) — install and sign in. See the [Gemini CLI install guide](https://github.com/google-gemini/gemini-cli#installation) if you need it.
-
-## 2. Install the Rhino plugin
-
-{{< yak package="Rhino-MCP-Platform" version="8" >}}
-{{< yak package="Rhino-MCP-Platform" version="9" >}}
-
-If that doesn't work you can try the below:
-
-1. Open Rhino 8 (and/or Rhino 9 WIP)
-2. Run the `PackageManager` command
-3. Search for, and install Rhino-MCP-Platform
-
-## 3. Wire up the Rhino MCP server
-
-1. In Rhino, run the `MCPConnect` command. It prints the command Gemini CLI needs to launch the Rhino MCP router.
-2. Open `~/.gemini/settings.json` (create it if it doesn't exist).
-3. Add an `mcpServers` entry for the Rhino server, pasting the command and args from step 1:
-
-   ```json
-   {
-     "mcpServers": {
-       "rhino": {
-         "command": "rhino-mcp-router",
-         "args": ["--default-version", "8"]
-       }
-     }
-   }
-   ```
-
-4. Restart Gemini CLI. The `rhino` server should appear when you list MCP servers from inside a session.
-
-> **Pick the Rhino version** by changing the `--default-version` arg.
-> Use `8` for Rhino 8, `9` for Rhino 9 WIP/BETA.
-
-## Try it out
-
-<blockquote class="page-note">
-Start a Gemini CLI session and follow the prompts on the <a href="../../try-it-out">Try It Out</a> page.
-</blockquote>