@hybridlabor-api/aos 4.9.0 → 4.10.0

package/THIRD_PARTY_NOTICES.md

@@ -287,6 +287,44 @@ the upstream offensive exploit content is stripped and not carried over.
 
 ---
 
+## talkvalue/event-agency-skills
+
+<https://github.com/talkvalue/event-agency-skills> — Apache-2.0.
+Copyright talkvalue contributors. Upstream carries no explicit copyright line
+in `README.md`, `CONTRIBUTING.md`, or the plugin manifests; the attribution
+above is the repository's own `LICENSE` grant.
+
+Prose techniques adapted into `skills/basic/bdb-eventagency-skill/SKILL.md`:
+stakeholder-type inbox classification with temporal priority overrides,
+vendor-type failure-impact tiers, phase-based escalation thresholds
+(T-30 → show day), BLOCKED-means-ours item semantics, the speaker materials
+deadline framework (D-30 / D-21 / D-14 / D-7 / D-1), and post-event
+performance-tier reporting. Upstream scripts, Composio tool bindings, and all
+Python were not carried over; the skill is self-contained prose with no
+dependency.
+
+---
+
+## BuilderIO/skills
+
+<https://github.com/BuilderIO/skills> — MIT. Copyright (c) 2026 Builder.io.
+
+One skill adapted into `skills/global_config/read-the-damn-docs/SKILL.md`:
+the docs-first trigger list, the source hierarchy, the required workflow, the
+must-trigger examples, and the "if docs are unavailable" rule. AOS additionally
+adds a Verification section, a `category:` key (Builder's own validator forbids
+one, AOS requires it), a division-of-labour note against the `AGENTS.md` *Zero
+guesswork* rule, and a pointer to the installed `firecrawl-search` /
+`firecrawl-scrape` tools. Prose only — the upstream `agents/openai.yaml` and
+README were not carried over, and no executable from the repo is referenced.
+
+The other 22 skills in that repo are **not** vendored. Six of them
+(`visual-plan`, `visual-recap`, `visual-edit`, `an`, `turn-into-app`, `rewind`)
+are build artefacts synced from a different upstream by
+`scripts/sync-agent-native-skills.mjs`, and the repo's own documentation says
+not to treat them as standalone. Its `.mcp.json` and plugin manifests register
+external HTTP MCP servers without a prompt, so the plugin surface must never be
+installed.
 ## obra/superpowers
 
 <https://github.com/obra/superpowers> — MIT. Copyright (c) 2025 Jesse Vincent.

package/bin/aos-doctor.mjs

@@ -201,7 +201,7 @@ function checkHarnesses() {
 // ---------------------------------------------------------------- 4. Hooks & Security Gates
 function checkHooks() {
   const claudeHooksDir = h('.claude', 'hooks');
-  const EXPECTED_VERSION = { 'memb-inject.mjs': 5 };
+  const EXPECTED_VERSION = { 'memb-inject.mjs': 6 };
   const versionOf = (text) => {
     const m = /^\/\/\s*aos-hook-version:\s*(\d+)/m.exec(text);
     return m ? Number(m[1]) : null;

package/installer.js

@@ -2921,7 +2921,7 @@ async function installMcpsForTarget(paths, ctx) {
     }
     log.step(`Installed selected MCP servers to ${mcpCodeTarget}`);
 
-    const nodeMcps = ['adobe_uxp_mcp', 'unreal_mcp', 'tdmcp', 'touchdesigner-mcp', 'davinci-resolve-mcp', 'after-effects-mcp', 'computer-use-mcp'];
+    const nodeMcps = ['adobe_uxp_mcp', 'unreal_mcp', 'tdmcp', 'touchdesigner-mcp', 'davinci-resolve-mcp', 'after-effects-mcp', 'computer-use-mcp', 'mcsc'];
     for (const mcpFolder of nodeMcps.filter(m => selectedMcps.includes(m))) {
         const targetFolder = path.join(mcpCodeTarget, mcpFolder);
         if (fs.existsSync(path.join(targetFolder, 'package.json'))) {
@@ -3469,13 +3469,17 @@ function compileCodexAgents(agents, targetDir, pipelineConfig = null) {
 
 
 function injectHarnessRules() {
-    const geminiMdSrc = path.join(srcDir, 'GEMINI.md');
+    const rulesMdSrc = path.join(srcDir, 'RULES.md');
     const agentsMdSrc = path.join(srcDir, '.agents', 'agents.md');
 
-    if (fs.existsSync(geminiMdSrc)) {
-        installStep(`install GEMINI.md to ${path.join(geminiDir, 'GEMINI.md')}`, () => {
-            copyDirRecursiveSync(geminiMdSrc, path.join(geminiDir, 'GEMINI.md'));
-            log.step(`Installed GEMINI.md to ${path.join(geminiDir, 'GEMINI.md')}`);
+    if (fs.existsSync(rulesMdSrc)) {
+        installStep(`install RULES.md to ${path.join(geminiDir, 'RULES.md')}`, () => {
+            copyDirRecursiveSync(rulesMdSrc, path.join(geminiDir, 'RULES.md'));
+            // Keep GEMINI.md in sync for backwards compatibility with Antigravity CLI harnesses
+            try {
+                fs.copyFileSync(rulesMdSrc, path.join(geminiDir, 'GEMINI.md'));
+            } catch (e) { logDebug(e, 'sync GEMINI.md fallback'); }
+            log.step(`Installed RULES.md to ${path.join(geminiDir, 'RULES.md')}`);
         }, 'The harness injection below still runs.');
 
         // Dispatcher scripts must land in ~/.claude/workflows/, because that is
@@ -3495,7 +3499,7 @@ function injectHarnessRules() {
 
         const startcycleWorkflowSrc = path.join(srcDir, '.agents', 'workflows', 'startcycle.md');
         const sources = installStep('read the global rule sources', () => ({
-            globalRules: fs.readFileSync(geminiMdSrc, 'utf8'),
+            globalRules: fs.readFileSync(rulesMdSrc, 'utf8'),
             startcycleContent: fs.existsSync(startcycleWorkflowSrc) ? fs.readFileSync(startcycleWorkflowSrc, 'utf8') : '',
             agentsMdContent: fs.existsSync(agentsMdSrc) ? fs.readFileSync(agentsMdSrc, 'utf8') : ''
         }), 'Cursor, Claude, Copilot and Codex keep their current instruction files.');
@@ -4914,7 +4918,7 @@ async function runQuickUpdate(installState) {
     pruneRemovedSkills(_sessionManifest);
     s.stop('Skills refreshed');
 
-    // Everything injectHarnessRules() delivers -- GEMINI.md, the dispatcher
+    // Everything injectHarnessRules() delivers -- RULES.md, the dispatcher
     // workflows the skills point at, the compiled subagent definitions, the
     // harness rule files and the gate + memory hooks -- used to be
     // fresh-install-only. v4.4.1 split just the hooks out of it for Quick
@@ -5087,7 +5091,7 @@ async function main() {
         path.join(srcDir, '.cursor'),
         path.join(srcDir, '.github'),
         path.join(srcDir, '.codex-plugin'),
-        path.join(srcDir, 'GEMINI.md'),
+        path.join(srcDir, 'RULES.md'),
         path.join(srcDir, 'AGENTS.md'),
         path.join(srcDir, 'CLAUDE.md'),
         path.join(srcDir, 'CODEX.md'),

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@hybridlabor-api/aos",
-  "version": "4.9.0",
+  "version": "4.10.0",
   "description": "AOS — A Curated AI AGENT OS. Optimized agent skills and add-ons like memB, OpenWiki, Heimdall Token Saver, and Godmode architectures.",
   "main": "installer.js",
   "engines": {
@@ -45,7 +45,7 @@
     "bin/",
     "lib/",
     "mcp_config.json",
-    "GEMINI.md",
+    "RULES.md",
     "CODEX.md",
     "CLAUDE.md",
     "THIRD_PARTY_NOTICES.md",

package/skills/basic/bdb-eventagency-skill/SKILL.md

@@ -0,0 +1,252 @@
+---
+name: bdb-eventagency-skill
+description: "Use for event agency operations: client intake, project scoping, vendor management, crew coordination, production planning, pre-show logistics, and post-show wrap. Delegates technical execution to godmode-eventtech and bdbmediastorm."
+category: media-eventtech
+source: talkvalue/event-agency-skills
+---
+
+# BDB Event Agency Skill
+
+The **agency-ops layer** for Hybridlabor Global — the business and production-coordination side of running an event company. This skill owns everything that happens *before, around, and after* the show. It does not own the technical execution itself.
+
+Techniques adapted from [talkvalue/event-agency-skills](https://github.com/talkvalue/event-agency-skills) (Apache-2.0). Prose only — no upstream code, no scripts, no dependencies.
+
+---
+
+## 1. Routing Table
+
+| Task | Route to |
+|---|---|
+| Signal flow, protocol binding, OSC/DMX, hardware limits, MCP orchestration | `godmode-eventtech` |
+| Live show architecture brainstorming, creative direction | `bdbmediastorm` |
+| Lighting cue execution, patch, playback | `bdb-grandma3-mcp` |
+| Video clip, layer, and output control | `bdb-resolume-mcp` |
+| 3D scene, render, spatial build | `godmode-3d-creation` |
+| Client intake, scoping, budget, scheduling, vendor, crew, pre-show logistics, post-show wrap | **stay in this skill** |
+
+**Boundary rule:** if the question is *"what should this look like"* or *"what signal goes where"*, route out. If it is *"who is bringing it, what did they promise, and what happens when they don't"*, it stays here. This skill never issues a technical execution instruction — it routes.
+
+---
+
+## 2. Client & Project Intake
+
+An event request is not a booking until these are known. Anything guessed here becomes a change order later.
+
+### Required fields before committing
+
+| Field | Why it is required | If missing |
+|---|---|---|
+| **Date** (and whether date or time is flexible) | Drives every downstream deadline in this skill | Cannot scope. Ask first. |
+| **Venue** (named, or shortlist with constraints) | Venue holds all vendor access; determines power, load-in window, noise curfew | Cannot plan load-in or vendor sequencing |
+| **Brief** — what must happen, who must be in the room | Distinguishes an event from a venue rental | Ask: *"What does success look like when the last guest leaves?"* |
+| **Budget range** — a band, not a number | Drives the action policy: which classes are `never` vs `criteria` | Do not quote. Scope verbally only. |
+| **Technical rider** | AV, staging, power, network, FOH position | Route to `godmode-eventtech` for feasibility |
+| **Attendance estimate** | Drives catering counts, staffing, registration, capacity | Cannot close catering or staffing |
+| **Client contact + decision authority** | Who can actually say yes | Every later "we'll confirm" is a no |
+
+### Scoping questions to ask before any commitment
+
+1. **Who signs?** Not "the client" — a name. The person who can approve a change order on show day.
+2. **What is non-negotiable?** Date, venue, budget, talent, or brand. Everything else is negotiable; know which one is not.
+3. **What has been promised already, in writing, to anyone?** Sponsors and speakers hold commitments that predate you.
+4. **What is the failure mode we are least able to absorb?** Late AV is a catastrophe; late florals are an inconvenience. Escalation urgency (§4) follows from this answer.
+5. **Is there a technical rider yet?** If not, that is a Phase 0 action, not a show-week action.
+
+### Scope statement rule
+
+Produce a written scope before any deposit. It must name: date, venue, attendance band, the ten action classes with their modes (default-deny — see `.aos/factory.yaml`), what is explicitly out of scope, and the change-order trigger. A scope without an out-of-scope list will be expanded by the client by default.
+
+---
+
+## 3. Inbox Triage
+
+Run this at the start of a working day on an active event, before a production meeting, or after time away. It produces a **point-in-time snapshot**, not a live feed.
+
+### Stakeholder classification
+
+| Type | Key signals | Default tier |
+|---|---|---|
+| **Vendor** | AV, catering, security, decor, transport, staffing, rentals, print | 2 |
+| **Client** | Contracting organisation, corporate domain, C-suite/VP | 2 |
+| **Sponsor** | Activation budget or in-kind contribution — **distinct from the client even when the client also sponsors** | 3 |
+| **Speaker** | Bureau domain, rider, session, keynote, bio/headshot request | 3 |
+| **Venue** | Hotel, convention centre, outdoor site, venue coordinator, venue-employed catering manager | 2 |
+| **Internal** | Own domain, team aliases, automated notifications | 3 |
+
+When a thread is ambiguous, default to the type with the higher production impact: **Vendor > Venue > Speaker** for operational threads.
+
+### Priority tiers
+
+| Tier | Label | Response window | Criteria |
+|---|---|---|---|
+| **1** | Immediate | 1–2 hours | Blocked deliverable, payment deadline within 48h, client waiting on confirmation, venue or vendor escalation, load-in unresolved within 72h of the event |
+| **2** | Today | Business hours | Advancing information requests, assets for review, draft approvals, speaker logistics more than 72h out |
+| **3** | Tracking | None | FYIs, confirmations of receipt, vendor acknowledgements, threads you are CC'd on |
+
+### Temporal override rules — apply before finalising tiers
+
+These override the table above:
+
+- Any vendor email mentioning **load-in, install, delivery window, or rider compliance** is Tier 1 if the event is within 14 days.
+- Any client email containing **a question in subject or body** is Tier 1.
+- Any Tier 1 thread with **no outbound reply in 24h+** escalates to flagged regardless of its original tier.
+
+**Rationale:** the tier table is a prior. The overrides exist because the failure mode of event email is a request that looked like an FYI and was not one.
+
+### Output shape
+
+A dated digest containing: event name, timestamp, event phase, period covered, counts per tier, then the tier-1 and tier-2 threads with the *specific* action each needs and who owns it. Every extracted action item must be one of:
+
+- **[OUR ACTION]** — a commitment we made, with a date
+- **[AWAITING]** — a commitment someone else made, with a date
+- **[APPROVAL NEEDED]** — a decision only the client can make
+
+Never mix these three. An action with no owner is not an action item.
+
+---
+
+## 4. Vendor Management
+
+Track **existing** vendor commitments and deliverables. This skill does not source vendors, negotiate contracts, or process payments.
+
+### Vendor types, lead times, and failure impact
+
+| Type | Typical lead time | Failure impact |
+|---|---|---|
+| AV / Technical | 2–4 weeks | **Critical** — no AV, no event |
+| Venue | Contracted months ahead | **Critical** — venue holds all vendor access |
+| Catering / F&B | 2–3 weeks (final count 72h) | High — dietary and count changes cascade |
+| Transport / Logistics | 1–2 weeks | High — gear and people movement |
+| Security | 1–2 weeks | High — compliance and safety |
+| Entertainment / Talent | Rider-dependent | High — contracted, non-fungible |
+| Decor / Floral | 1–2 weeks | Medium — visual, not operational |
+| Staffing Agencies | 1–2 weeks | Medium — replaceable if flagged early |
+| Signage / Print | 5–10 business days | Medium — wayfinding and branding |
+| Rentals | 1 week | Medium — tables, chairs, linens |
+
+### Phase-based urgency
+
+Urgency is relative to **event proximity**, never absolute time. The same 48-hour silence is fine in month one and a production risk in advance week.
+
+| Phase | Window | Overdue threshold | Escalation speed |
+|---|---|---|---|
+| Normal | T-30 and out | 48h no response | Standard: email → wait → follow-up |
+| Planning | T-30 to T-8 | 24h no response | Accelerated: email → same-day follow-up |
+| Advance | T-7 to T-2 | 12h no response | Urgent: email → phone within 4h |
+| Load-in | T-1 | 2h no response | Emergency: phone immediately, escalate to production lead |
+| Show day | T-0 | 1h no response | Emergency: phone + contingency activation |
+
+### Item status taxonomy
+
+| Status | Meaning |
+|---|---|
+| **OVERDUE** | Past deadline, no confirmation |
+| **AT RISK** | Deadline approaching, last contact exceeds the phase threshold |
+| **ON TRACK** | Confirmed, or within the normal response window |
+| **BLOCKED** | **Waiting on us, not the vendor** |
+
+**BLOCKED items are the most important row in the table and are routinely under-reported.** When a vendor is waiting on our headcount, floor plan, or approval, that is our team's problem. Surface it first.
+
+### Escalation path
+
+| Attempt | AV / Venue / Catering | Decor / Signage / Rentals | Staffing / Transport |
+|---|---|---|---|
+| 1st | Follow-up email quoting the original request | Follow-up email | Follow-up email |
+| 2nd | Phone the account manager within 4h | Phone next business day | Phone next business day |
+| 3rd | Escalate to production lead + contingency research | Source a backup vendor | Source a backup vendor |
+
+**On show day: skip email entirely. Phone or in-person only.** Never send a follow-up email on T-0.
+
+### Drafting rules for vendor follow-ups
+
+- Reference the **specific** original request or deliverable — not "following up on my last email".
+- State the deadline explicitly.
+- Ask for a **specific confirmation** ("Can you confirm delivery by 14 March?"), not an open question.
+- **No guilt, no pressure.** Vendors respond better to clarity than to escalation tone.
+- For a phone call, prepare: vendor name, account manager, the specific item, the deadline and why it matters, and the fallback question — *"If the original plan isn't possible, what's the alternative?"*
+
+### Budget and invoice context
+
+| Age | Status | Action |
+|---|---|---|
+| Within terms | Current | None |
+| 1–30 days | Nudge | Friendly reminder — assume oversight |
+| 31–60 days | Firm request | Direct ask with date and amount |
+| 60+ days | Escalation | Account lead; consider late fee or hold |
+
+Variance alerts: **Venue 5% over** (largest single line, small % = big dollars), **Catering 10%** (per-head counts fluctuate), **Marketing 15%** (most flexible), **Contingency 0% drawn before T-14** (should not be touched), **all others 10%**.
+
+---
+
+## 5. Production Coordination
+
+### 5.1 Pre-production
+
+**Site survey — non-negotiable for any first-time venue.** Record: power distribution and available amperage by area, network drops and their throughput, load-in vehicle access and dock dimensions, door widths for the largest scenic element, FOH position and sightlines, noise curfew, and rigging points with their load ratings. Route the technical read to `godmode-eventtech` — this skill records the findings and flags blockers, it does not validate the signal plan.
+
+**Paperwork gate.** Nothing loads in without: certificate of insurance (COI) from every vendor on site, venue access permits, and crew credentials. These are the most common cause of a T-1 access failure.
+
+**Run-of-show (ROS) is the single coordination artefact.** One document, versioned, owned by the production lead, distributed to every vendor. It defines: load-in window and sequence, soundcheck, doors, show start, each cue block, and load-out. A conflict discovered in the ROS is cheap. A conflict discovered at the dock is not.
+
+**Speaker materials — deadline framework:**
+
+| Milestone | Due | Deliverables |
+|---|---|---|
+| D-30 | Bio (25 / 50 / 100-word variants, third person) + headshot (min 300×300px) | |
+| D-21 | Session abstract (75 words, attendee-focused), learning outcomes, AV requirements | |
+| D-14 | Final slide deck, event template applied | |
+| D-7 | Travel, hotel, ground transport, dietary and accessibility requirements | |
+| D-1 | Attendance and schedule confirmed | |
+
+Learning outcomes use action verbs only — **implement, apply, build, create, deploy, evaluate, identify, master**. Never: *explore, discuss, learn about, understand, discover, dive into, unpack*.
+
+Banned in any bio or session description: *thought leader, visionary, guru, passionate about, world-class, cutting-edge, revolutionary, groundbreaking, leverage, synergize, transformative, innovative*. Replace with specific numbers, named clients, measurable outcomes, concrete credentials.
+
+### 5.2 Day-of flow
+
+| Phase | Anchor | What must be true to advance |
+|---|---|---|
+| **Load-in** | T-1 or earlier | COI and permits verified per vendor, power patched and tested, ROS sequence confirmed with the dock |
+| **Soundcheck** | Fixed slot, never "when ready" | Line check done, cue stack loaded, FOH and monitors positioned, walk-through with the client if contracted |
+| **Doors** | Published start | House open, accessibility routes clear, front-of-house briefed on the ROS |
+| **Show** | Per cue block | Production lead confirms each block against the ROS; deviations logged, not improvised |
+| **Strike** | After clearance | Equipment accounted for against the load-in manifest, rentals checked out before the truck leaves |
+
+**The strike manifest is the load-in manifest.** Count on the way in, count on the way out. Rentals left on site are invoiced at loss.
+
+### 5.3 Post-show wrap
+
+Within 72 hours of strike:
+
+- **Debrief** — what worked, what did not, what nearly failed. Blameless, specific, and it feeds the next ROS.
+- **Invoice triggers** — headcount actuals vs. quoted, rental shortfalls, overtime hours, damage claims. Capture while the evidence exists.
+- **Thank-you and forward look** — personalised, referencing what the attendee actually did, not a broadcast.
+- **Asset archiving** — recorded content, photography, final ROS, run sheets, and the vendor contact list with performance notes, filed where the next production can find them.
+- **Vendor performance note per vendor** — this is the input to §4's escalation tiers for the next event. A vendor who delivered three times running is not escalated on the first silence.
+
+### 5.4 Post-event reporting
+
+Performance tiers: **Exceeded** (beat goal by 10%+ on primary metrics), **Met** (within 10%), **Missed** (more than 10% below on one or more), **Mixed** (hit some, missed others — say which and why).
+
+Report structure: performance summary → what worked (with evidence) → what did not (with likely cause) → key insights (each tied to a data point) → specific recommendations for the next event → sponsor ROI if applicable.
+
+Channel attribution is **inherently imperfect** — most attendees meet several touchpoints before registering. Report it honestly, acknowledge mixed sources, and never over-credit a single channel.
+
+---
+
+## 6. Verification
+
+- [ ] Every event is classified into a phase (Normal / Planning / Advance / Load-In / Show Day) and that classification is stated, not assumed.
+- [ ] Urgency thresholds are applied relative to event proximity, not absolute days.
+- [ ] Every BLOCKED item names our team as owner — no BLOCKED item is left attributed to a vendor.
+- [ ] Technical execution questions were routed to `godmode-eventtech` / `bdbmediastorm` rather than answered from this skill.
+- [ ] No signal-flow, protocol, hardware-limit, or cue-execution instruction was issued from this skill.
+- [ ] COI, permits, and crew credentials are confirmed before load-in, per vendor.
+- [ ] The run-of-show is versioned, distributed, and owned by the production lead.
+- [ ] Speaker materials are checked against the D-30 / D-21 / D-14 / D-7 / D-1 framework.
+- [ ] Banned fluff words are absent from every bio, abstract, and session description.
+- [ ] On show day, no vendor follow-up was sent by email.
+- [ ] The strike manifest reconciles against the load-in manifest.
+- [ ] Invoice triggers captured within 72 hours of strike.
+- [ ] Attribution figures are presented with their acknowledged uncertainty.
+- [ ] No upstream script, Python file, or Composio tool dependency was added.

package/skills/basic/bdb-shipping-skill/SKILL.md

@@ -0,0 +1,161 @@
+---
+name: bdb-shipping-skill
+description: "Use before starting any significant build or before shipping: problem-framing pre-flight, one-way/two-way door classification, ADR-lite decision logging, and post-ship outcome loop. Complements godmode-shipping (technical gate) and bdbresilience (error recovery)."
+category: engineering-method
+---
+
+# BDB Shipping Skill — Pre-Flight, Door Classification, ADR-lite, Post-Ship Loop
+
+This skill fills the four decision-quality gaps that neither `godmode-shipping` nor `bdbresilience` covers:
+
+- `godmode-shipping` → technical release gate (tests, checklist, feature flags, rollback, CI). Load it for that.
+- `bdbresilience` → error recovery, 429-backoff, distributed locking, fault taxonomy. Load it for that.
+- This skill → problem framing, reversibility classification, decision logging, outcome verification. Load it for this.
+
+---
+
+## Routing Table
+
+| Situation | Skill to load |
+|---|---|
+| Running pre-launch checks, CI gate, WCAG, feature flags | `godmode-shipping` |
+| Handling transient errors, rate limits, concurrent locks | `bdbresilience` |
+| Starting a significant build — framing the problem | **this skill** |
+| Making a one-way or two-way door decision | **this skill** |
+| Recording a significant architectural choice | **this skill** |
+| Confirming a ship actually delivered value | **this skill** |
+
+Significant build means any work that takes more than one commit, touches a public contract, or requires a decision that is not immediately reversible. For a one-liner fix or a pure chore, skip this skill.
+
+---
+
+## 1. Pre-Build Problem-Framing (Pre-Flight)
+
+Run these five questions before the first file is written. The answers go into the ADR-lite entry (section 3) or, for smaller work, into the commit message or PR description. A question with no answer is a blocker — do not proceed until it is answered.
+
+**Q1 — What problem does this solve?**
+State the user-visible or system-visible problem in one sentence. If you cannot write that sentence, the problem is not understood yet.
+
+**Q2 — Why now, not next sprint?**
+Name the forcing function: a deadline, a blocking dependency, a cost that compounds if delayed. "It would be nice" is not a forcing function.
+
+**Q3 — What is explicitly out of scope?**
+List at least one thing that is tempting but excluded. Scope creep almost always enters through an unguarded boundary. Write the boundary down.
+
+**Q4 — What does success look like, measurably?**
+Name a metric, a threshold, or an observable outcome that confirms the work delivered its value. "It works" is not measurable. "Error rate on /api/export drops below 0.1%" or "user can complete onboarding in under 3 steps" is.
+
+**Q5 — Is this reversible?**
+Classify the change (see section 2). If it is a one-way door, written justification is required before proceeding.
+
+---
+
+## 2. One-Way / Two-Way Door Classification
+
+Before any irreversible change, name the door type. Gate accordingly.
+
+### Two-Way Doors — can proceed normally
+Changes that can be undone with low cost and no external impact:
+- UI layout, copy, styling changes
+- Internal refactors with no API surface changes
+- Configuration behind a feature flag
+- Adding a new optional endpoint (additive-only)
+- Internal test infrastructure changes
+
+Two-way door work proceeds when pre-flight (section 1) passes. No extra gate.
+
+### One-Way Doors — require written justification and explicit GO
+Changes that cannot be undone without significant cost, coordination, or external impact:
+- Public API contract changes (breaking or removing a field, endpoint, or behavior)
+- Database schema changes (especially dropping columns, changing types, removing tables)
+- Published npm package versions (`npm publish` / `npm version`)
+- Pricing or billing model changes
+- Security model changes (auth scheme, permission structure, encryption at rest)
+- Removing or renaming a public CLI command or config key
+- Any change that alters an external integration contract other parties depend on
+
+**Gate for one-way doors:**
+1. Write one sentence stating: what is changing, why it cannot be reversed, and what the migration/recovery path is for any party depending on it.
+2. Paste that sentence into the ADR-lite entry (section 3) under `Reversibility`.
+3. Wait for explicit GO before executing. The GO rule from AGENTS.md applies: a plan is read-only until the user replies with the literal word GO.
+
+### When the classification is unclear
+Default to one-way. The cost of an unnecessary GO gate is one conversation turn. The cost of treating a one-way door as reversible is potentially irreversible.
+
+---
+
+## 3. ADR-lite Decision Log
+
+Record any significant architectural or product decision — including every one-way door — using this format. Lightweight by design: one file per significant choice, stored in `docs/decisions/` or `production_artifacts/decisions/`. File name: `YYYY-MM-DD-<slug>.md`.
+
+```markdown
+# ADR: <title, max 60 characters>
+
+**Date:** YYYY-MM-DD
+**Status:** proposed | accepted | superseded-by ADR-YYYY-MM-DD-<slug>
+
+## Context
+One sentence: the situation that made this decision necessary.
+
+## Options Considered
+- Option A: <what it is and why it was considered>
+- Option B: <what it is and why it was considered>
+- (add more; delete this line if only one option was viable)
+
+## Decision
+<Which option was chosen, in one or two sentences.>
+
+## Reversibility
+- Type: one-way | two-way
+- Migration path (one-way only): <what a party depending on the old behavior must do>
+
+## Revisit Trigger
+<The specific event or metric that would make this decision worth re-examining.
+Examples: "If p95 latency on this path exceeds 200ms after the migration",
+"If a second consumer needs to read this field", "After Q1 usage data is available.">
+```
+
+Store the file. Reference it from the PR description. You do not need a framework, a tool, or a meeting — just the file.
+
+---
+
+## 4. Post-Ship Outcome Loop
+
+Define the check-back before the ship, not after. At the time of shipping, record this alongside the ADR-lite entry or in the PR description:
+
+**Check-back trigger:** When will you look? Choose one:
+- Time-based: "Check in N days." (N = 7 for most features; 1 for anything touching the critical path.)
+- Metric-based: "Check when [metric] reaches [threshold]."
+
+**Success signal:** What observable outcome confirms the work delivered its stated value (from Q4 above)?
+
+**Rollback signal:** What observable outcome triggers rollback consideration? Be specific: name the metric and threshold. "Something seems wrong" is not a signal. "Error rate on the affected endpoint exceeds 1% over a 15-minute window" is.
+
+**Who checks?** Default: the person who shipped it. If that person is unavailable, name a fallback now.
+
+Post-ship check is not optional for one-way door changes. For two-way door changes it is recommended but can be skipped if the change is trivially observable (e.g., a style change that is visible on first load).
+
+---
+
+## 5. Common Rationalizations
+
+| Rationalization | Reality |
+|---|---|
+| "I'll define success after I ship." | Success defined post-hoc matches whatever shipped, not what the user needed. Write it before. |
+| "This is just a small refactor, the door classification doesn't apply." | Classification is fastest on small changes. The blast radius of a wrong call on a large change makes the small effort worthwhile. |
+| "I'll write the ADR after the decision is stable." | A decision that has already shipped is not a decision — it is a fact. Write it when options are still open. |
+| "The rollback trigger is obvious, I don't need to write it down." | Obvious rollback signals are still missed under incident pressure. Write the number before the incident. |
+| "The post-ship check-back is someone else's job." | If no one is named, no one owns it. Name someone before shipping. |
+
+---
+
+## 6. Verification Checklist
+
+Before calling this skill's work done:
+
+- [ ] All five pre-flight questions answered (section 1)
+- [ ] Door type classified — one-way or two-way (section 2)
+- [ ] If one-way: written justification present and GO received before execution
+- [ ] ADR-lite entry created for any significant decision or one-way door change, stored in `docs/decisions/` or `production_artifacts/decisions/`
+- [ ] Post-ship check-back defined: trigger, success signal, rollback signal, owner (section 4)
+- [ ] ADR-lite entry referenced from the PR description or commit message

package/skills/basic/godmode-eventtech/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: godmode-eventtech
-description: "Use when designing real-time live performance architectures, signal flows, protocol routings (OSC, DMX), or validating hardware limits."
+description: "Use for real-time performance and multimedia operator work: technical show-control execution (signal flows, OSC/DMX, MCP orchestration, hardware limits) for tools like grandMA3, Resolume, Unreal, Rhino, Vectorworks, and Adobe MCP."
 category: media-eventtech
 ---
 
@@ -12,6 +12,9 @@ This skill is the architectural authority for **Real-Time Performance, Signal Fl
 
 ## 1. Role & Architectural Boundaries
 
+For agency-layer tasks (vendor management, production coordination, inbox triage,
+pre-show logistics), load `bdb-eventagency-skill` alongside this skill.
+
 * **Real-Time & Live Show Authority:** Focuses on deterministic frame timing, zero-latency signal routing, hardware boundaries, and physical protocol management (OSC, Art-Net, sACN, DMX, MIDI, SMPTE, NDI, Spout/Syphon).
 * **Peer Integration:** Operates alongside specialized media and 3D creation skills, enforcing strict hardware stability, network bandwidth limits, and live-environment fault tolerance across all event technology systems.
 

package/skills/global_config/aos-project-init/SKILL.md

@@ -139,6 +139,8 @@ When the user chose to watch it, add the absolute path to `projects` in
 `~/.openwiki/projects.json` — that file is the daemon's watch list. Merge into
 it; never rewrite it.
 
+**Domain Registration (WORKTREE.md)**: Every project belongs to a domain (e.g., `~/dev/bdb-dev/`). To ensure multi-agent navigation works, the parent domain directory must have a `WORKTREE.md` acting as a map. Check if `../WORKTREE.md` exists. If it does, append a link to this new project specifying its Slug, Domain, active Harnesses, and a pointer to its `.aos/project.json`. If it doesn't exist, create it with a simple markdown list structure.
+
 For memB, write the project card through the MCP with the slug as `project_id`
 and `project_card` as `category` — domain-category rows are dead weight, since
 the hook whitelist only injects `project_card`/`godmode`:

package/skills/global_config/aos-project-init/assets/AGENTS.template.md

@@ -3,7 +3,7 @@
 One-paragraph description of what this project is and who uses it. An agent
 that reads only this file should understand what it is touching.
 
-> Harness files: `CLAUDE.md`, `GEMINI.md` and `CODEX.md` are symlinks to this
+> Harness files: `CLAUDE.md`, `RULES.md` and `CODEX.md` are symlinks to this
 > file. Every rule lives here exactly once.
 
 ## Stack

package/skills/global_config/aos-project-init/scripts/aos-project-doctor.mjs

@@ -83,7 +83,7 @@ function checkAgentDocs() {
   add('docs', 'AGENTS.md', existsSync(agents), existsSync(agents) ? `${readFileSync(agents, 'utf8').split('\n').length} lines` : 'missing — no repo-specific agent rules',
     'Write AGENTS.md (see the /aos-project-init template).');
 
-  for (const alias of ['CLAUDE.md', 'GEMINI.md', 'CODEX.md']) {
+  for (const alias of ['CLAUDE.md', 'RULES.md', 'CODEX.md']) {
     const f = p(alias);
     let ok = false; let detail = 'missing';
     if (existsSync(f)) {

package/skills/global_config/aos-setup/SKILL.md

@@ -232,7 +232,7 @@ harness was never installed into.
 context is written into the rule files that harness loads instead:
 
 ```bash
-python3 ~/.agents/memB/memb_auto_inject.py --global      # GEMINI.md, CODEX.md, …
+python3 ~/.agents/memB/memb_auto_inject.py --global      # RULES.md, CODEX.md, …
 python3 ~/.agents/memB/memb_auto_inject.py --dir <repo>  # a project's AGENTS.md
 ```
 

package/skills/global_config/aos-setup/scripts/aos-doctor.mjs

@@ -174,7 +174,7 @@ function checkHooks() {
   // the row would go green over a hook carrying a bug this version fixed.
   // Hooks that carry an `aos-hook-version:` line are checked against what this
   // release expects; the ones that do not are existence-only.
-  const EXPECTED_VERSION = { 'memb-inject.mjs': 5 };
+  const EXPECTED_VERSION = { 'memb-inject.mjs': 6 };
   const versionOf = (text) => {
     const m = /^\/\/\s*aos-hook-version:\s*(\d+)/m.exec(text);
     return m ? Number(m[1]) : null;

package/skills/global_config/ask-tim/SKILL.md

@@ -45,9 +45,9 @@ Reach for `test-driven-development` or `tdd-workflow` on their own when you want
 
 When no native AOS skill fits, search the markdown-only ECC store before starting a pipeline:
 
-- `aos store search <query>` finds available fallback skills and agents.
-- `aos store install <name> --net` installs a verified item after explicit user action.
-- `aos store list --type=skills` and `aos store list --type=agents` show the catalogue.
+- `aos-store search <query>` finds available fallback skills and agents.
+- `aos-store install <name> --net` installs a verified item after explicit user action.
+- `aos-store list --type=skills` and `aos-store list --type=agents` show the catalogue.
 - The core remains the trusted AOS skill set; the store is a fallback, not a reason to bypass the startcycle validation.
 - A missing `--skill` is reported by the dispatcher with the exact install command. It never downloads during a run.
 

package/skills/global_config/deja-memory/SKILL.md

@@ -8,7 +8,9 @@ source: bdb
 
 # deja: On-Demand Session Memory
 
-`deja` indexes this machine's agent transcripts into a local, secret-redacted store and answers three questions on demand. It is installed together with memB. There is no boot sequence — never call deja at session start; reach for it at one of the moments below.
+`deja` indexes this machine's agent transcripts into a local, secret-redacted store and answers three questions on demand. It is installed together with memB.
+
+The session start is already covered: the memB hook (`memb-inject.mjs`) appends `deja wip` for the current project to its SessionStart block, under "Last session here". Read that instead of calling `deja wip` yourself at start; reach for deja at one of the moments below.
 
 ## 1. An error just happened