@hybridlabor-api/aos 4.8.0 → 4.10.0

package/skills/global_config/{MCP_Manage → mcp-manage}/SKILL.md

@@ -1,10 +1,10 @@
 ---
-name: MCP_Manage
+name: mcp-manage
 description: "Use when checking capabilities or instructing the user on how to interact with specialized MCP servers like Unreal, Rhino, DaVinci, or TouchDesigner."
 category: media-eventtech
 ---
 
-# MCP_Manage: Specialized Tool Orchestration
+# MCP Manage: Specialized Tool Orchestration
 
 You are the authoritative skill for managing and utilizing the specialized Model Context Protocol (MCP) servers installed in this environment. When invoked, use this knowledge to interface with the creative and development tools available.
 
@@ -59,7 +59,7 @@ You are the authoritative skill for managing and utilizing the specialized Model
 
 
 ## Overview
-MCP_Manage is the authoritative router for all specialized BDB Model Context Protocol (MCP) servers, ensuring the AI agent selects the right tool for Unreal, Rhino, DaVinci, and others.
+mcp-manage is the authoritative router for all specialized BDB Model Context Protocol (MCP) servers, ensuring the AI agent selects the right tool for Unreal, Rhino, DaVinci, and others.
 
 ## When to Use
 - **Trigger:** The user asks how to automate a specific creative app, or the agent needs to select the correct MCP server for a domain-specific task.

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/requesting-code-review/SKILL.md

@@ -0,0 +1,98 @@
+---
+name: requesting-code-review
+description: Use when completing tasks, implementing major features, or before merging to verify work meets requirements
+category: engineering-method
+source: superpowers
+date_added: "2026-09-25"
+---
+
+# Requesting Code Review
+
+Dispatch a code reviewer subagent to catch issues before they cascade. The reviewer gets precisely crafted context for evaluation — never your session's history.
+
+**Core principle:** Review early, review often.
+
+## When to Request Review
+
+**Mandatory:**
+- After each task in subagent-driven development
+- After completing major feature
+- Before merge to main
+
+**Optional but valuable:**
+- When stuck (fresh perspective)
+- Before refactoring (baseline check)
+- After fixing complex bug
+
+## How to Request
+
+**1. Get git SHAs:**
+```bash
+BASE_SHA=$(git rev-parse HEAD~1)  # or: git merge-base origin/main HEAD
+HEAD_SHA=$(git rev-parse HEAD)
+```
+
+**2. Dispatch code reviewer subagent:**
+
+Dispatch a `general-purpose` subagent, filling the template at [code-reviewer.md](code-reviewer.md)
+
+**Placeholders:**
+- `{DESCRIPTION}` - Brief summary of what you built
+- `{PLAN_OR_REQUIREMENTS}` - What it should do
+- `{BASE_SHA}` - Starting commit
+- `{HEAD_SHA}` - Ending commit
+
+**3. Act on feedback:**
+- Fix Critical issues immediately
+- Fix Important issues before proceeding
+- Note Minor issues for later
+- Push back if reviewer is wrong (with reasoning)
+
+## Example
+
+```
+[Just completed Task 2: Add verification function]
+
+You: Let me request code review before proceeding.
+
+BASE_SHA=$(git log --oneline | grep "Task 1" | head -1 | awk '{print $1}')
+HEAD_SHA=$(git rev-parse HEAD)
+
+[Dispatch code reviewer subagent]
+  DESCRIPTION: Added verifyIndex() and repairIndex() with 4 issue types
+  PLAN_OR_REQUIREMENTS: Task 2 from docs/superpowers/plans/deployment-plan.md
+  BASE_SHA: a7981ec
+  HEAD_SHA: 3df7661
+
+[Subagent returns]:
+  Strengths: Clean architecture, real tests
+  Issues:
+    Important: Missing progress indicators
+    Minor: Magic number (100) for reporting interval
+  Assessment: Ready to proceed
+
+You: [Fix progress indicators]
+[Continue to Task 3]
+```
+
+## Common Rationalizations
+
+| Excuse | Reality |
+|--------|---------|
+| "I'll just review the diff myself instead of dispatching a reviewer" | You're the coordinator — reviewing the diff inline burns the context window you need to keep driving the work. Dispatch a reviewer subagent: the diff and the evaluation live in its context, and only the findings come back to you. |
+| "The reviewer needs my whole session history to understand the change" | Hand it precisely crafted context, never your session's history. That keeps the reviewer on the work product, not your thought process. |
+
+## Red Flags
+
+**Never:**
+- Skip review because "it's simple"
+- Ignore Critical issues
+- Proceed with unfixed Important issues
+- Argue with valid technical feedback
+
+**If reviewer wrong:**
+- Push back with technical reasoning
+- Show code/tests that prove it works
+- Request clarification
+
+See template at: [code-reviewer.md](code-reviewer.md)

package/skills/global_config/requesting-code-review/code-reviewer.md

@@ -0,0 +1,198 @@
+# Code Reviewer Prompt Template
+
+Use this template when dispatching a code reviewer subagent.
+
+**Purpose:** Review completed work against requirements and code quality standards before it cascades into more work.
+
+```
+Subagent (general-purpose):
+  description: "Review code changes"
+  prompt: |
+    You are a Senior Code Reviewer with expertise in software architecture,
+    design patterns, and best practices. Your job is to review completed work
+    against its plan or requirements and identify issues before they cascade.
+
+    ## What Was Implemented
+
+    [DESCRIPTION]
+
+    ## Requirements / Plan
+
+    [PLAN_OR_REQUIREMENTS]
+
+    ## Git Range to Review
+
+    **Base:** [BASE_SHA]
+    **Head:** [HEAD_SHA]
+
+    ```bash
+    git diff --stat [BASE_SHA]..[HEAD_SHA]
+    git diff [BASE_SHA]..[HEAD_SHA]
+    ```
+
+    ## The spec is a vision document
+
+    The spec says what the software must do. It does not enumerate every
+    input, environment, or condition the software will meet. For behavior
+    the spec is silent on, judge by what a reasonable person using this
+    software would expect: a reasonable person's expectation is a
+    requirement, and a spec's silence is not permission. Grade such
+    findings by their effect on that person, not by whether the spec
+    mentions the trigger.
+
+    ## Declined to judge
+
+    Before your verdict, list every behavior you considered and set aside
+    as outside the plan or spec, one line each, with the reason. The
+    executor rules on each line; nothing you set aside is dropped
+    silently. An empty list means you set nothing aside.
+
+    ## Read-Only Review
+
+    Your review is read-only on this checkout. Do not mutate the working tree, the index, HEAD, or branch state in any way. Use tools like `git show`, `git diff`, and `git log` to inspect history. If you need a working copy of a different revision, check it out into a separate temporary directory (e.g. `git worktree add /tmp/review-[SHA] [SHA]`) — never move HEAD on this checkout.
+
+    ## You Do Not Dispatch Subagents
+
+    Do all of this review yourself. Never spawn a subagent to review part
+    of the diff, and never spawn another reviewer for a second opinion.
+    This process already provides every review seat the work gets; a
+    reviewer you spawn duplicates one of them at full cost, and its
+    verdict counts for nothing. If the diff feels too large for one
+    pass, review it in passes yourself and say so in your report.
+
+    ## What to Check
+
+    **Plan alignment:**
+    - Does the implementation match the plan / requirements?
+    - Are deviations justified improvements, or problematic departures?
+    - Is all planned functionality present?
+
+    **Code quality:**
+    - Clean separation of concerns?
+    - Proper error handling?
+    - Type safety where applicable?
+    - DRY without premature abstraction?
+    - Edge cases handled?
+
+    **Architecture:**
+    - Sound design decisions?
+    - Reasonable scalability and performance?
+    - Security concerns?
+    - Integrates cleanly with surrounding code?
+
+    **Testing:**
+    - Tests verify real behavior, not mocks?
+    - Edge cases covered?
+    - Integration tests where they matter?
+    - All tests passing?
+
+    **Production readiness:**
+    - Migration strategy if schema changed?
+    - Backward compatibility considered?
+    - Documentation complete?
+    - No obvious bugs?
+
+    ## Calibration
+
+    Categorize issues by actual severity. Not everything is Critical.
+    Acknowledge what was done well before listing issues — accurate praise
+    helps the implementer trust the rest of the feedback.
+
+    If you find significant deviations from the plan, flag them specifically
+    so the implementer can confirm whether the deviation was intentional.
+    If you find issues with the plan itself rather than the implementation,
+    say so.
+
+    ## Output Format
+
+    ### Strengths
+    [What's well done? Be specific.]
+
+    ### Issues
+
+    #### Critical (Must Fix)
+    [Bugs, security issues, data loss risks, broken functionality]
+
+    #### Important (Should Fix)
+    [Architecture problems, missing features, poor error handling, test gaps]
+
+    #### Minor (Nice to Have)
+    [Code style, optimization opportunities, documentation polish]
+
+    For each issue:
+    - File:line reference
+    - What's wrong
+    - Why it matters
+    - How to fix (if not obvious)
+
+    ### Recommendations
+    [Improvements for code quality, architecture, or process]
+
+    ### Assessment
+
+    **Ready to merge?** [Yes | No | With fixes]
+
+    **Reasoning:** [1-2 sentence technical assessment]
+
+    ## Critical Rules
+
+    **DO:**
+    - Categorize by actual severity
+    - Be specific (file:line, not vague)
+    - Explain WHY each issue matters
+    - Acknowledge strengths
+    - Give a clear verdict
+
+    **DON'T:**
+    - Say "looks good" without checking
+    - Mark nitpicks as Critical
+    - Give feedback on code you didn't actually read
+    - Be vague ("improve error handling")
+    - Avoid giving a clear verdict
+```
+
+**Placeholders:**
+- `[DESCRIPTION]` — brief summary of what was built
+- `[PLAN_OR_REQUIREMENTS]` — what it should do (plan file path, task text, or requirements)
+- `[BASE_SHA]` — starting commit
+- `[HEAD_SHA]` — ending commit
+
+**Reviewer returns:** Strengths, Issues (Critical / Important / Minor), Recommendations, Assessment
+
+## Example Output
+
+```
+### Strengths
+- Clean database schema with proper migrations (db.ts:15-42)
+- Comprehensive test coverage (18 tests, all edge cases)
+- Good error handling with fallbacks (summarizer.ts:85-92)
+
+### Issues
+
+#### Important
+1. **Missing help text in CLI wrapper**
+   - File: index-conversations:1-31
+   - Issue: No --help flag, users won't discover --concurrency
+   - Fix: Add --help case with usage examples
+
+2. **Date validation missing**
+   - File: search.ts:25-27
+   - Issue: Invalid dates silently return no results
+   - Fix: Validate ISO format, throw error with example
+
+#### Minor
+1. **Progress indicators**
+   - File: indexer.ts:130
+   - Issue: No "X of Y" counter for long operations
+   - Impact: Users don't know how long to wait
+
+### Recommendations
+- Add progress reporting for user experience
+- Consider config file for excluded projects (portability)
+
+### Assessment
+
+**Ready to merge: With fixes**
+
+**Reasoning:** Core implementation is solid with good architecture and tests. Important issues (help text, date validation) are easily fixed and don't affect core functionality.
+```