@polderlabs/bizar 10.7.1 → 10.7.2

package/.claude/skills/thinking-triz/SKILL.md

@@ -0,0 +1,171 @@
+---
+name: thinking-triz
+description: Use when stuck between two architecture or API requirements that seem mutually exclusive — name the contradiction precisely, then separate the conflicting states in time, space, or condition.
+---
+
+# TRIZ Thinking
+
+## Overview
+
+TRIZ is a systematic method for resolving **architecture and API design contradictions** — situations where two requirements seem mutually exclusive. When you're about to accept a trade-off because "you can't have both," TRIZ says: name the contradiction precisely, then try to **separate** the conflicting states in time, space, or condition so you get both — no compromise.
+
+The separation moves are the primary procedure. The 40 Inventive Principles are a reference library, not a required checklist. The skill is scoped to technical design contradictions (architecture, API, system parameters); it is NOT for non-technical problems, ordinary prioritization, or contradictions that dissolve under measurement.
+
+**Core Principle:** Great design doesn't compromise — it separates. Find the dimension where the conflicting states can coexist.
+
+## When to Use
+
+- An architecture or API design decision is stuck between two requirements that seem mutually exclusive (fast vs accurate, stable vs evolving, large cache vs fast invalidation)
+- You're about to accept a trade-off because "you can't have both"
+- The same weakness shows up in every solution you've considered — the contradiction is structural
+
+Decision flow:
+
+```
+Two requirements seem mutually exclusive?
+  → Yes → NAME THE CONTRADICTION, TRY SEPARATION
+  → No → About to accept a trade-off curve compromise?
+      → Yes → APPLY TRIZ FIRST
+      → No → This is a routine decision — just pick based on constraints
+```
+
+## When NOT to Use
+
+- **Ordinary trade-offs with a correct answer.** If one option is simply better given your constraints (cheaper, simpler, well-understood), just pick it — don't manufacture a contradiction.
+- **The "contradiction" dissolves under measurement.** If you can cheaply test which side actually matters, do that instead of inventing a separation.
+- **Non-technical or people problems.** Separation principles target system parameters, not organizational dynamics or interpersonal conflicts.
+- **The contradiction is already well-solved by standard patterns.** If there's an established pattern (cache-aside, CQRS, feature flags), apply the pattern directly.
+
+## Trigger Card
+
+When stuck between two architecture or API requirements that seem mutually exclusive:
+
+1. **Name the contradiction precisely** — "We need [PARAMETER A] to be [STATE 1] for [BENEFIT 1] BUT also [STATE 2] for [BENEFIT 2]." If you can't write it in this form, it's not a TRIZ problem.
+2. **Try separation** — can you satisfy state 1 at one TIME and state 2 at another? In different SPACES (components, layers)? Under different CONDITIONS (context, load, user)?
+3. **Test the simplest separation first** — separate in time (feature flags, scheduled behavior) before space (separate services) before condition.
+
+If one option is simply better given your constraints, just pick it. If you can cheaply test which side actually matters, test instead of designing a separation. For standard patterns (cache-aside, CQRS, feature flags), apply the pattern directly.
+
+## Procedure
+
+### Step 1: Name the Contradiction Precisely
+
+Use this template:
+
+```
+"We need [PARAMETER A] to be [STATE 1] for [BENEFIT 1]
+ BUT also [STATE 2] for [BENEFIT 2]"
+
+Example:
+"We need the API to be STABLE for client compatibility
+ BUT also EVOLVING to support new features"
+```
+
+If you can't write the contradiction in this form, it's not a TRIZ problem — use another skill.
+
+### Step 2: Envision the Ideal Final Result (IFR)
+
+Before solving, describe the outcome where the problem solves itself:
+
+```
+"The API supports both old and new clients simultaneously,
+without version negotiation overhead,
+while maintaining a single codebase."
+```
+
+IFR questions: What if the problem solved itself? What if the harmful element became useful? What's the result with zero cost?
+
+### Step 3: Try Separation Moves (Primary Procedure)
+
+For each separation dimension, ask: "Can the conflicting states exist at different [times/places/conditions/scales]?"
+
+#### Separation in Time
+
+"Can we be in state 1 at one time and state 2 at another?"
+
+```
+Contradiction: "Cache must be FRESH AND cached"
+Separation in Time: TTL-based invalidation — cached now, refreshed later
+```
+
+#### Separation in Space
+
+"Can we be in state 1 in one place and state 2 in another?"
+
+```
+Contradiction: "Data must be LOCAL (fast) AND DISTRIBUTED (resilient)"
+Separation in Space: Multi-region with local reads, distributed writes
+```
+
+#### Separation by Condition
+
+"Can we be in state 1 under some conditions and state 2 under others?"
+
+```
+Contradiction: "Auth must be STRICT AND frictionless"
+Separation by Condition: Strict for sensitive operations, frictionless for low-risk — risk-based authentication
+```
+
+#### Separation in Scale/Level
+
+"Can state 1 and state 2 exist at different levels of the system?"
+
+```
+Contradiction: "API must be STABLE AND evolving"
+Separation in Scale: Stable interface (API contract), evolving implementation — versioned APIs
+```
+
+### Step 4: If Separation Fails, Scan the Principles (Reference)
+
+When no separation dimension resolves the contradiction, scan the software-adapted inventive principles for inspiration:
+
+| Principle | Software Pattern |
+|-----------|-----------------|
+| Segmentation (#1) | Microservices, sharding, chunked processing |
+| Preliminary Action (#10) | Pre-computation, caching, warm-up, materialized views |
+| The Other Way Round (#13) | Push vs pull, invert control, event-driven instead of polling |
+| Intermediary (#24) | Proxy, message queue, API gateway, adapter |
+| Copying (#26) | Caching, replication, CDN, read replicas |
+| Dynamization (#15) | Feature flags, runtime configuration, adaptive thresholds |
+| Another Dimension (#17) | Add metadata layer, versioning, event sourcing |
+
+The full 40 principles are reference material; scan only the most applicable ones.
+
+### Step 5: Resource Analysis
+
+Before adding new components, ask: what already exists that can be used?
+
+```
+Before: "We need a new service to track user sessions"
+Resource check:
+- What data already exists? → Auth tokens carry user identity
+- What's already running? → Load balancer sees all requests
+- What's unused? → Request headers have room for session ID
+Solution: Encode session in existing auth flow — no new service
+```
+
+### Step 6: Synthesize and Decide
+
+Combine the separation move with resource reuse into a concrete design decision. Document the contradiction, the separation dimension used, and the resolution.
+
+## Output Contract
+
+A completed TRIZ analysis produces:
+
+1. **Contradiction Statement** — in the precise template form (Parameter A must be State 1 for Benefit 1 BUT State 2 for Benefit 2)
+2. **Ideal Final Result** — what the self-solving outcome looks like
+3. **Separation Attempts** — which dimensions were tried (time, space, condition, scale) and the result
+4. **Principles Scanned** (if separation failed) — which inventive principles were considered
+5. **Resources Used** — what existing capabilities were leveraged before adding new ones
+6. **Resolution** — the concrete design decision that resolves the contradiction without compromise
+
+## Anti-Patterns
+
+| Anti-Pattern | Symptom | Correction |
+|---|---|---|
+| **Manufacturing contradictions** | Applying TRIZ to "which database should we use" when one is clearly better | Use it only for genuine "I need both opposite states" tension |
+| **Compromising instead of separating** | Accepting a midpoint on the trade-off curve without trying separation | Try all four separation dimensions before compromising |
+| **Skipping separation, jumping to principles** | Immediately scanning the 40 principles without trying time/space/condition/scale | Separation is the primary procedure; principles are the fallback |
+| **Applying to non-technical problems** | Using TRIZ for org dynamics or interpersonal conflicts | Separation targets system parameters, not people |
+| **Over-applying to testable contradictions** | Running full TRIZ when a pam measurement resolves which side matters | If you can test it cheaply, test it |
+| **Ignoring existing resources** | Adding new components when existing ones could be reused | Resource analysis before new component proposals |

package/.claude/skills/thinking-via-negativa/SKILL.md

@@ -0,0 +1,358 @@
+---
+name: thinking-via-negativa
+description: About to add a feature/layer/process to fix a problem. First ask what to remove instead — subtraction is often more robust than addition. Use for simplification and complexity reduction.
+---
+
+# Via Negativa
+
+## Overview
+
+Via Negativa, articulated by Nassim Taleb in "Antifragile," is the principle that improvement often comes from subtraction rather than addition. We're biased toward adding (features, processes, complexity) when removing (bugs, friction, unnecessary work) often provides more value with less risk.
+
+**Core Principle:** Focus on what to remove, not what to add. Subtraction is more robust than addition.
+
+## When to Use
+
+- System simplification
+- Process improvement
+- Feature prioritization (what NOT to build)
+- Performance optimization
+- Reducing technical debt
+- Personal productivity
+- Decision-making (what to avoid)
+- Code review (what to delete)
+
+Decision flow:
+
+```
+Trying to improve something?
+  → First instinct is to add? → yes → PAUSE, CONSIDER SUBTRACTION
+  → Can you achieve the goal by removing instead? → yes → REMOVE FIRST
+  → Is current complexity necessary? → no → SIMPLIFY VIA NEGATIVA
+```
+
+## When NOT to Use
+
+- **Never subtract a load-bearing control, test, validation, guard, or safety check** just because it's "extra complexity." Removal is only low-risk when the thing is genuinely unused or redundant. A test you don't understand, an error handler, a rate limiter, an auth check, or a retry are presumed load-bearing — prove they're dead before deleting. The whole "subtraction is safe" claim holds only for things that provide no benefit.
+- **Not when the addition is genuinely required** to meet a real, demonstrated need. Via negativa fights the *reflex* to add; it doesn't forbid all addition.
+- **Don't delete to hit an aesthetic "less is more" target** without checking what each element does — confirm non-use with evidence (usage data, dead-code analysis, removing it in a branch and watching), not assumption.
+
+## Trigger Card
+
+When about to add a feature, layer, or process to fix a problem:
+
+1. **Ask: "What can I remove instead?"** — before adding, scan for something to subtract that would have the same or better effect.
+2. **Identify the highest-cost, lowest-usage candidates** — what's consuming resources (code, process, dependency) but delivering the least value?
+3. **Remove the simplest one first** — subtraction is asymmetric: removing is safer than adding because you can always add back. Test by removing it in a branch and seeing what breaks.
+
+Don't delete to hit an aesthetic target without checking what each element does — confirm non-use with evidence, not assumption. If the addition is genuinely required for a real, demonstrated need, add it — via negativa fights the reflex to add, not all addition.
+
+## The Via Negativa Process
+
+### Step 1: Identify What to Eliminate
+
+Instead of "What should we add?", ask:
+
+```
+- What's not working that we should remove?
+- What's causing harm we should stop?
+- What's unnecessary complexity we should eliminate?
+- What's outdated that we should delete?
+```
+
+### Step 2: Catalog Candidates for Removal
+
+List elements that might be subtracted:
+
+```markdown
+## Candidates for Removal
+
+Code:
+- Dead code (unreachable)
+- Deprecated features (still running)
+- Unused dependencies
+- Redundant abstractions
+
+Process:
+- Meetings that don't produce decisions
+- Approval steps that don't add value
+- Reports no one reads
+- Alerts no one acts on
+
+Features:
+- Low-usage functionality
+- Legacy features maintained "just in case"
+- Edge cases that complicate the core
+```
+
+### Step 3: Evaluate Impact of Removal
+
+For each candidate:
+
+```markdown
+| Element | Usage | Maintenance Cost | Risk of Removal | Value of Removal |
+|---------|-------|------------------|-----------------|------------------|
+| Feature X | 0.1% of users | 20 hrs/month | Low | High |
+| Meeting Y | 8 people | 4 hrs/week | None | High |
+| Process Z | 5 approvers | 2 days/request | Medium | Medium |
+```
+
+### Step 4: Remove with Monitoring
+
+Subtract and verify no harm:
+
+```markdown
+Week 1: Remove Feature X for 10% of users
+Week 2: Monitor complaints, metrics
+Week 3: If no issues, remove for 50%
+Week 4: Full removal and code deletion
+```
+
+## Via Negativa Patterns
+
+### Subtractive Design
+
+Add by removing:
+
+```
+Goal: Make the product easier to use
+Additive approach: Add tutorial, tooltips, help section
+Via Negativa: Remove confusing features, simplify flow, delete options
+
+Often more effective:
+- Fewer choices = easier decisions
+- Less surface area = less to learn
+- Simpler UI = faster adoption
+```
+
+### The Pruning Principle
+
+Healthy growth requires pruning:
+
+```
+Codebase:
+- Every feature has maintenance cost
+- Old features create complexity tax
+- Pruning unused code enables healthier growth
+
+Team:
+- Every process has coordination cost
+- Old processes accumulate like barnacles
+- Pruning enables focus on what matters
+```
+
+### Harm Reduction Over Benefit Addition
+
+Removing bad is often more impactful than adding good:
+
+```
+Performance:
+- Removing one slow query helps more than adding one cache
+- Eliminating N+1 beats adding read replicas
+- Deleting unused indexes beats adding new ones
+
+Health (Taleb's domain):
+- Removing sugar helps more than adding supplements
+- Stopping smoking beats starting exercise
+- Eliminating stress beats adding meditation
+```
+
+### The 80/20 Removal
+
+Remove the 80% that provides 20% of value:
+
+```markdown
+## Feature Usage Analysis
+
+| Feature | Users | Revenue | Maintenance |
+|---------|-------|---------|-------------|
+| Core A | 90% | 70% | 20% |
+| Core B | 85% | 25% | 15% |
+| Edge C | 5% | 3% | 25% |
+| Edge D | 2% | 2% | 40% |
+
+Via Negativa: Remove Edge C and D
+Result: 65% less maintenance for 5% of value
+        Enables focus on Core A and B
+```
+
+## Application Areas
+
+### Code
+
+```markdown
+## Via Negativa Code Review
+
+Before adding new code, ask:
+1. Can we solve this by removing existing code?
+2. Is there dead code to delete?
+3. Are there unused imports/dependencies?
+4. Is there duplication to consolidate?
+5. Are there unnecessary abstractions?
+
+Rule: Every PR should delete at least as much as it adds
+      (aspirational, not mandatory)
+```
+
+### Process
+
+```markdown
+## Via Negativa Process Audit
+
+List all recurring processes:
+- Daily standup (15 min/day × 8 people = 10 hrs/week)
+- Sprint planning (2 hrs × 8 people = 16 hrs/sprint)
+- Weekly status report (2 hrs to write)
+- Monthly review (4 hrs × 5 people = 20 hrs/month)
+
+For each, ask:
+- What happens if we stop?
+- Can we reduce frequency?
+- Can we reduce attendees?
+- Can we reduce duration?
+
+Often: Half the meetings, half the reports = more productive
+```
+
+### Features
+
+```markdown
+## Via Negativa Product Strategy
+
+Instead of roadmap of additions, create:
+
+## Sunset List
+| Feature | Usage | Decision | Timeline |
+|---------|-------|----------|----------|
+| Export to CSV | 0.5% | Remove | Q2 |
+| Legacy API v1 | 2% | Deprecate | Q3 |
+| Advanced filters | 3% | Simplify | Q2 |
+
+## Maintenance Liberation
+Removing 3 features frees 2 engineers for core work
+
+## Simplicity Gains
+- Fewer code paths to test
+- Smaller attack surface
+- Easier onboarding
+- Faster development
+```
+
+### Personal Productivity
+
+```markdown
+## Via Negativa for Focus
+
+Don't add:
+- More productivity apps
+- More systems
+- More commitments
+
+Instead remove:
+- Notifications
+- Unnecessary meetings
+- Low-value tasks
+- Context switching
+- Decision fatigue (reduce choices)
+
+"Stop doing" list > "To do" list
+```
+
+### Architecture
+
+```markdown
+## Via Negativa Architecture Review
+
+Before adding complexity, audit existing:
+
+Services to consolidate:
+- Microservice A and B do similar things → Merge
+- Service C has one caller → Inline
+
+Dependencies to remove:
+- Library X is used for one function → Write function
+- Framework Y is overkill → Use lighter alternative
+
+Layers to eliminate:
+- Abstraction that has one implementation → Remove
+- API that wraps another API identically → Direct call
+```
+
+## Via Negativa Template
+
+```markdown
+# Via Negativa Analysis: [System/Process/Product]
+
+## Current State
+[Description of what exists]
+
+## Candidates for Removal
+
+### Category 1: Unused/Dead
+| Element | Evidence of Non-Use | Removal Risk |
+|---------|---------------------|--------------|
+| | | |
+
+### Category 2: Low-Value High-Cost
+| Element | Value Provided | Maintenance Cost | Ratio |
+|---------|---------------|------------------|-------|
+| | | | |
+
+### Category 3: Redundant
+| Element | Duplicated By | Removal Path |
+|---------|---------------|--------------|
+| | | |
+
+## Removal Priority
+1. [Element] - [Why first]
+2. [Element] - [Why second]
+
+## Removal Plan
+| Element | Week | Monitor | Rollback |
+|---------|------|---------|----------|
+| | | | |
+
+## Expected Benefits
+- Reduced complexity: [Measure]
+- Freed resources: [Measure]
+- Improved focus: [Measure]
+```
+
+## The Lindy Connection
+
+Via Negativa aligns with Lindy:
+- Old things that have survived removal attempts are robust
+- New additions are fragile, unproven
+- Subtracting recent additions is lower risk than adding new things
+
+## Verification Checklist
+
+- [ ] Asked "what can we remove?" before "what should we add?"
+- [ ] Identified candidates for removal in multiple categories
+- [ ] Evaluated usage/value of removal candidates
+- [ ] Planned gradual removal with monitoring
+- [ ] Considered second-order effects of removal
+- [ ] Resisted the urge to add when subtraction would work
+
+## Key Questions
+
+- "What can we remove instead of add?"
+- "What would happen if we stopped doing this?"
+- "What's the maintenance cost of this existing thing?"
+- "Is this complexity earning its keep?"
+- "What should we stop doing?"
+- "What would we not build if starting from scratch?"
+
+## Taleb's Wisdom
+
+"The first principle of iatrogenics: we do not need evidence of harm to claim that a treatment is harmful; we need evidence of benefit to claim it is not harmful."
+
+Applied to software: We don't need evidence that a feature is actively harmful to remove it; we need evidence it provides benefit to keep it.
+
+"Via Negativa is more powerful than Via Positiva: omission does less harm than commission."
+
+Removing is safer than adding. Every addition has unknown side effects. Removal of recent additions reverts to a known-good state. When in doubt, subtract.
+
+"The best way to live is to maximize the number of decisions not made."
+
+Reduce decisions through simplification. Fewer features = fewer decisions to make. Fewer processes = fewer coordination points. Simpler is more robust.

package/cli/install/postinstall.mjs

@@ -1,58 +1,84 @@
 /**
  * cli/install/postinstall.mjs
  *
- * runPostInstall() — moved verbatim from cli/install.mjs (original ~95 lines).
+ * runPostInstall() — bootstrap after npm install. Sets up the Claude Code
+ * config dir with the canonical Bizar agents + a starter settings.json, and
+ * installs Semble / Skills CLI as sidecars.
+ *
+ * Source paths resolve via `import.meta.url` so they work both when the
+ * package is extracted to `node_modules/@polderlabs/bizar/` (npm install)
+ * and when invoked from a local checkout (`node cli/bin.mjs install`).
+ *
+ * v10.7.2 fix: source paths previously used `PATHS.bizarHome + '/../config/'`
+ * which resolved to a nonexistent `~/.config/config/` (one level up from
+ * `BIZAR_HOME`, which is a runtime state dir, not the package source). After
+ * F-107 deleted the legacy `config/agents/` tree, the install couldn't find
+ * any agent files and crashed with ENOENT.
  */
 
 import chalk from 'chalk';
-import { existsSync, mkdirSync, copyFileSync } from 'node:fs';
+import { existsSync, mkdirSync, copyFileSync, readdirSync } from 'node:fs';
 import { execSync } from 'node:child_process';
-import { join } from 'node:path';
+import { join, dirname } from 'node:path';
+import { fileURLToPath } from 'node:url';
 import { resolveClaudeDir, PATHS } from './paths.mjs';
 
-const AGENT_FILES = [
-  'mike.md', 'janet.md', 'susan.md', 'pam.md',
-  'greg.md', 'brenda.md', 'steve.md', 'todd.md', 'brad.md',
-  'karen.md', 'carl.md', 'linda.md',
-  'oscar.md',
-];
+/** Package root — `node_modules/@polderlabs/bizar/` or the checkout root. */
+const PACKAGE_ROOT = join(dirname(fileURLToPath(import.meta.url)), '..', '..');
+
+/** Source paths, all relative to the package root. */
+const SRC_AGENTS_DIR    = join(PACKAGE_ROOT, '.claude', 'agents');
+const SRC_SETTINGS_FILE = join(PACKAGE_ROOT, '.claude', 'settings.json');
+
+/**
+ * Discover every agent .md shipped in `.claude/agents/`. Replaces the prior
+ * hardcoded AGENT_FILES list (which omitted kevin and brad and broke
+ * whenever a new agent was added).
+ */
+function listShippedAgents() {
+  if (!existsSync(SRC_AGENTS_DIR)) return [];
+  return readdirSync(SRC_AGENTS_DIR).filter(f => f.endsWith('.md'));
+}
 
 /**
  * Post-install bootstrap: settings.json template, agents, Semble, Skills CLI.
  * Called by the npm postinstall hook.
  */
 export async function runPostInstall() {
-  const dest = join(resolveClaudeDir(), 'settings.json');
-  const templateSrc = join(PATHS.bizarHome, '..', 'config', 'settings.json');
-
-  // Copy settings.json template if not exists
-  if (!existsSync(dest)) {
-    if (existsSync(templateSrc)) {
+  // 1. settings.json — copy template if user has none yet.
+  const destSettings = join(resolveClaudeDir(), 'settings.json');
+  if (!existsSync(destSettings)) {
+    if (existsSync(SRC_SETTINGS_FILE)) {
       mkdirSync(resolveClaudeDir(), { recursive: true });
-      copyFileSync(templateSrc, dest);
+      copyFileSync(SRC_SETTINGS_FILE, destSettings);
       console.log('  ✓ settings.json bootstrapped from package template');
+    } else {
+      console.warn('  ⚠ settings.json template not found at', SRC_SETTINGS_FILE);
     }
   }
 
-  // Ensure Claude config dir exists
-  const env = { exists: existsSync(resolveClaudeDir()) };
-  if (!env.exists) {
+  // 2. Make sure Claude config dir exists.
+  if (!existsSync(resolveClaudeDir())) {
     mkdirSync(resolveClaudeDir(), { recursive: true });
     console.log(`BizarHarness: created ${resolveClaudeDir()}/`);
   }
 
+  // 3. Copy agent files. Skip ones the user already has (don't clobber).
   mkdirSync(PATHS.agentsDir, { recursive: true });
-
-  for (const file of AGENT_FILES) {
-    const src = join(PATHS.bizarHome, '..', 'config', 'agents', file);
+  const agents = listShippedAgents();
+  if (agents.length === 0) {
+    console.warn(`BizarHarness: no agent files found at ${SRC_AGENTS_DIR} — package is broken.`);
+  }
+  for (const file of agents) {
+    const src = join(SRC_AGENTS_DIR, file);
     const dst = join(PATHS.agentsDir, file);
     if (!existsSync(dst)) {
       copyFileSync(src, dst);
     }
   }
-  console.log('BizarHarness: agents installed.');
+  console.log(`BizarHarness: ${agents.length} agent(s) installed.`);
 
-  // Install Semble
+  // 4. Install Semble (code search MCP).
   const seemeCmd = (cmd) => {
     try {
       execSync(`command -v ${cmd}`, { stdio: ['ignore', 'pipe', 'ignore'] });
@@ -80,7 +106,7 @@ export async function runPostInstall() {
     console.log('BizarHarness: Semble ready.');
   }
 
-  // Install Skills CLI
+  // 5. Install Skills CLI.
   const skillsPresent = seemeCmd('skills');
   if (!skillsPresent) {
     console.log('BizarHarness: installing Skills CLI...');
@@ -94,7 +120,7 @@ export async function runPostInstall() {
     console.log('BizarHarness: Skills CLI ready.');
   }
 
-  // Install core skill pack
+  // 6. Install core skill pack.
   console.log('BizarHarness: installing core skills...');
   try {
     execSync('skills add vercel-labs/skills --all -y', { stdio: 'pipe', timeout: 60000 });
@@ -103,9 +129,9 @@ export async function runPostInstall() {
     console.log('BizarHarness: core skill install skipped — run `skills add vercel-labs/skills --all -y` manually.');
   }
 
-  // Install Bizar plugin
+  // 7. Install Bizar plugin.
   const { installPluginFromGlobal } = await import('./plugin.mjs');
   await installPluginFromGlobal();
 
   console.log('Run `bizar` for interactive setup.');
-}
+}