@polderlabs/bizar 10.7.2 → 10.11.0

package/templates/plan/library/bug-investigation.mdx

@@ -1,79 +0,0 @@
-# Bug: {{title}}
-
-**Status:** `[STATUS:draft]` · **Author:** {{author}} · **Created:** {{created}}
-
-> [!DANGER]
-> Severity: <high/medium/low> · Reported: <date> · Reporter: <name>
-
-## Summary
-
-_One-paragraph description of the bug._
-
-## Reproduction
-
-Steps to reproduce:
-1. Step 1
-2. Step 2
-3. ...
-
-## Expected vs Actual
-
-**Expected:** What should happen.
-
-**Actual:** What actually happens.
-
-## Environment
-
-- App version: <version>
-- OS: <os>
-- Browser: <browser>
-- Account: <test-account-id> (if reproducible only on certain accounts)
-
-## Investigation
-
-> [!NOTE]
-> Document the timeline of what you tried, what you found, and what
-> you ruled out. Link to relevant logs, traces, or screenshots.
-
-### What we tried
-
-- Tried X — found Y
-- Tried A — ruled out B
-
-### What we found
-
-- Observation 1
-- Observation 2
-
-## Root cause
-
-> [!WARNING]
-> State the underlying cause clearly. If the cause is unknown, say so
-> and list the most likely candidates.
-
-_The underlying issue._
-
-## Fix
-
-> [!TIP]
-> Describe the proposed fix. Include a code diff or a sketch of the
-> change. Note any follow-up work that's needed but out of scope here.
-
-_The proposed fix._
-
-## Test plan
-
-- [ ] Test that the bug is fixed (regression test on the failing case)
-- [ ] Test that the fix doesn't break anything (existing tests still pass)
-- [ ] Add a regression test to the suite
-- [ ] Manual verification in staging
-
-## Rollback plan
-
-_How do we revert if the fix makes things worse?_
-
-## References
-
-- [PR #X](https://example.com/pr/X)
-- [Slack thread](https://example.com/slack)
-- [Related incidents](#)

package/templates/plan/library/decision-record.mdx

@@ -1,71 +0,0 @@
-# Decision: {{title}}
-
-**Status:** `[STATUS:draft]` · **Author:** {{author}} · **Date:** {{created}}
-
-> [!INFO]
-> This is an **Architecture Decision Record (ADR)**. It captures a
-> significant decision, the context that led to it, and the consequences
-> that follow. Once accepted, ADRs are immutable — create a new ADR to
-> supersede this one.
-
-## Context
-
-_What is the situation? What forces are at play? What problem are we
-trying to solve? What constraints do we have?_
-
-## Options considered
-
-### Option A: <name>
-
-_Brief description._
-
-- Pros: …
-- Cons: …
-
-### Option B: <name>
-
-_Brief description._
-
-- Pros: …
-- Cons: …
-
-### Option C: <name>
-
-_Brief description._
-
-- Pros: …
-- Cons: …
-
-## Decision
-
-> [!TIP]
-> State the chosen option and the rationale. Quote relevant constraints
-> from the Context section. Note any dissent.
-
-We chose **Option X** because…
-
-## Consequences
-
-### Positive
-
-- …
-
-### Negative
-
-- …
-
-### Neutral
-
-- …
-
-## Follow-ups
-
-- [ ] Follow-up 1
-- [ ] Follow-up 2
-- [ ] Follow-up 3
-
-## References
-
-- [Doc 1](https://example.com/doc-1)
-- [Doc 2](https://example.com/doc-2)
-- [Related ADRs](#)

package/templates/plan/library/feature-design.mdx

@@ -1,92 +0,0 @@
-# Feature: {{title}}
-
-**Status:** `[STATUS:draft]` · **Author:** {{author}} · **Created:** {{created}}
-
-> [!INFO]
-> This is a v2 plan with the **feature-design** template. It uses callouts
-> (`> [!INFO]`, `> [!WARNING]`, etc.), status badges, and GFM task lists.
-> See https://example.com for more on these conventions.
-
-## Problem
-
-_What problem are we solving? Why now? What happens if we don't?_
-
-## Goals
-
-- [ ] Goal 1 — a concrete, measurable outcome
-- [ ] Goal 2 — another concrete, measurable outcome
-- [ ] Goal 3 — and one more for good measure
-
-## Non-goals
-
-- This feature does NOT do X (deferred to a future plan)
-- This feature does NOT cover Y (out of scope for this iteration)
-
-## Design
-
-The proposed approach. Walk through the high-level shape, then drill into specifics.
-
-### Architecture
-
-```mermaid
-graph LR
-  Client --> API --> DB
-  API --> Cache
-```
-
-### Data model
-
-Tables, schemas, types. Show diffs or new shapes.
-
-### API
-
-_Endpoints, request/response shapes, error handling._
-
-### Edge cases
-
-- What if X is empty?
-- What if Y is malformed?
-- What if the user is offline?
-
-## Tradeoffs
-
-| Option | Pros | Cons |
-|--------|------|------|
-| A      | Simple, easy to roll back | Limited to use case 1 |
-| B      | Handles more cases       | More complex, more tests |
-
-## Files affected
-
-- `path/to/file.ts` — what changes and why
-- `path/to/other.ts` — what changes and why
-- `path/to/migration.sql` — schema changes
-
-## Open questions
-
-1. Question 1?
-2. Question 2?
-3. Question 3?
-
-## Test plan
-
-- [ ] Unit tests for the new module
-- [ ] Integration tests for the API surface
-- [ ] E2E test for the user flow
-- [ ] Manual QA in staging
-
-## Rollout
-
-- [ ] Dev
-- [ ] Staging
-- [ ] Production (% rollout)
-
-## Decision
-
-> [!TIP]
-> Pick option **A** or **B** and state the rationale here. Reference the
-> Tradeoffs table above. Link to relevant docs / RFCs.
-
-## References
-
-- [Design doc](https://example.com/design)
-- [Related plan](#)

package/templates/plan/meta.json.template

@@ -1,8 +0,0 @@
-{
-  "title": "{{title}}",
-  "slug": "{{slug}}",
-  "status": "draft",
-  "author": "{{author}}",
-  "created": "{{created}}",
-  "lastEdited": "{{lastEdited}}"
-}

package/templates/plan/plan.mdx.template

@@ -1,46 +0,0 @@
-# {{title}}
-
-**Slug:** {{slug}} · **Status:** Draft · **Author:** {{author}} · **Created:** {{created}}
-
----
-
-## Overview
-
-_A short description of what this plan is about._
-
-## Goals
-
-- [ ] Goal 1
-- [ ] Goal 2
-
-## Non-Goals
-
-- What this plan does **not** cover
-
-## Background
-
-_Context and motivation for this plan._
-
-## Detailed Plan
-
-### Phase 1: Foundation
-
-_First steps._
-
-### Phase 2: Core Implementation
-
-_Main work._
-
-### Phase 3: Validation
-
-_Testing and verification._
-
-## Open Questions
-
-1. _Question 1_
-2. _Question 2_
-
-## References
-
-- [Link 1]
-- [Link 2]

package/templates/plugin-template/README.md

@@ -1,121 +0,0 @@
-# Echo Plugin Template
-
-The smallest possible Bizar marketplace plugin. Use it as a starting
-point for your own — copy this folder, rename the fields in
-`plugin.json`, replace the body of `index.js`, and ship it as a
-`.tar.gz`.
-
-## What you get
-
-```
-plugin-template/
-├── plugin.json     # manifest (id, name, version, main, exports, permissions)
-├── index.js        # the plugin's main entry — exports { init, echo, shout }
-├── README.md       # you are here
-└── tests/
-    └── plugin.test.js   # node:test smoke tests
-```
-
-## Trying it locally
-
-You can sanity-check the template without publishing it: install it
-from a local path (or just point the host at this folder directly):
-
-```bash
-# From inside your dashboard's project:
-bizar plugin install <path-to-plugin-template>
-bizar plugin info echo
-bizar plugin invoke echo echo "hello world"
-# → echo: hello world
-
-bizar plugin config echo greeting "yo"
-bizar plugin invoke echo shout "hello world"
-# → SHOUT: HELLO WORLD
-
-bizar plugin uninstall echo
-```
-
-## Publishing
-
-1. **Pick an id.** It must match `/^[a-z0-9][a-z0-9-]*$/`. Lowercase
-   kebab-case is the convention (`vercel-deploy`, `github-pr-watcher`).
-
-2. **Edit `plugin.json`** — at minimum:
-   - `id`, `name`, `version`, `description`
-   - `main` (relative to the tarball root)
-   - `exports` (array of method descriptors; drives the dashboard UI)
-   - `permissions` (every `api.*` method you'll use, except `console`,
-     `api.config.*`, and `api.log` which are always available)
-
-3. **Write the plugin code** in `index.js`. Use `module.exports = { ... }`
-   and export plain async functions. Every async method is awaited by
-   the host; a thrown error becomes `{ ok: false, error, code }` on the
-   wire.
-
-4. **Package the tarball.** Standard convention:
-
-   ```bash
-   tar czf echo-0.1.0.tar.gz plugin.json index.js tests
-   ```
-
-   The tarball root must contain `plugin.json` (either at the very
-   top of the archive or inside a single top-level directory — both
-   work).
-
-5. **Compute the SHA-256** of the tarball:
-
-   ```bash
-   sha256sum echo-0.1.0.tar.gz
-   # → 8a3f... (64 hex chars)
-   ```
-
-6. **Submit to the registry** by opening a PR against
-   [DrB0rk/bizar-plugins](https://github.com/DrB0rk/bizar-plugins).
-   Add your entry under `plugins:` in `registry.json`:
-
-   ```json
-   {
-     "id": "echo",
-     "name": "Echo",
-     "version": "0.1.0",
-     "description": "Echo plugin",
-     "author": "you",
-     "category": "utility",
-     "tags": ["example", "template"],
-     "tarball": "https://github.com/.../echo-0.1.0.tar.gz",
-     "checksum": "sha256:8a3f...",
-     "permissions": [],
-     "minBizarVersion": "4.9.0"
-   }
-   ```
-
-   The host verifies the checksum before extracting — a tampered
-   tarball is rejected outright.
-
-7. **Install.** Once merged:
-
-   ```bash
-   bizar plugin install echo
-   ```
-
-## Sandbox permissions
-
-| Permission   | What it unlocks                                      |
-|--------------|------------------------------------------------------|
-| `net`        | `api.http.get(url)`, `api.http.post(url, body)`      |
-| `fs:read`    | `api.fs.read(path)` — sandboxed to the plugin root   |
-| *(none)*     | `api.config.*`, `api.log`, `console.*` are free      |
-
-Anything else (`process`, `child_process`, raw `fs`, `net`) is
-stripped from the plugin's global scope by `node:vm`. A plugin that
-tries `require('node:fs')` will throw `require is not defined`.
-
-## Versioning
-
-Bizar plugins use [semver](https://semver.org/). Bump the major
-version for any breaking change to `plugin.json`'s `exports[]`; minor
-for new methods; patch for bugfixes.
-
-## License
-
-MIT, same as the rest of BizarHarness.

package/templates/plugin-template/index.js

@@ -1,66 +0,0 @@
-/**
- * Echo plugin — the minimal marketplace plugin.
- *
- * Plugins export their public methods via `module.exports`. Each
- * method receives `(args..., { config, api, plugin })`. The host
- * (bizar-dash's plugin store) handles sandboxing, timeouts, and
- * permission enforcement — your code just needs to focus on the
- * domain logic.
- *
- * What you CAN do from inside a plugin:
- *   - console.log / console.error    → routed through the dashboard's logger
- *   - api.http.get(url)              → only if you declare "net" permission
- *   - api.fs.read(path)              → only if you declare "fs:read" permission
- *   - api.config.get(key) / set(key, value)   → in-memory + persisted to disk
- *   - api.log(level, msg)            → structured logger with your plugin id
- *
- * What you CANNOT do (the sandbox strips these globals):
- *   - require('node:fs') directly    → use api.fs.read instead
- *   - require('node:child_process')  → not allowed in v1
- *   - process.exit / process.kill    → use api.log instead
- *   - require('node:net')            → use api.http instead
- */
-'use strict';
-
-/**
- * The plugin's `init` hook. Called once after install and on every
- * dashboard start (the host caches the loaded plugin). Use it to
- * warm caches, validate config, or subscribe to events.
- *
- * Returning a Promise is fine — the host awaits it.
- */
-async function init() {
-  // Pull a config value the user may have set.
-  const greeting = api.config.get('greeting') || 'echo';
-  api.log('info', `${plugin.id} v${plugin.version} initialized (greeting="${greeting}")`);
-}
-
-/**
- * The simplest possible plugin method: return the input verbatim,
- * prefixed with the configured greeting.
- *
- * @param {string} message
- */
-async function echo(message) {
-  if (typeof message !== 'string') {
-    throw new Error(`echo: expected string, got ${typeof message}`);
-  }
-  const greeting = api.config.get('greeting') || 'echo';
-  return `${greeting}: ${message}`;
-}
-
-/**
- * Upper-cased variant — demonstrates that async / await / Promises
- * all work transparently inside the sandbox.
- *
- * @param {string} message
- */
-async function shout(message) {
-  return `SHOUT: ${String(message).toUpperCase()}`;
-}
-
-module.exports = {
-  init,
-  echo,
-  shout,
-};

package/templates/plugin-template/plugin.json

@@ -1,42 +0,0 @@
-{
-  "id": "echo",
-  "name": "Echo",
-  "version": "0.1.0",
-  "description": "A minimal example plugin — echoes whatever you send it. Use this as a starting template for your own marketplace plugin.",
-  "author": "DrB0rk",
-  "main": "index.js",
-  "exports": [
-    {
-      "name": "echo",
-      "args": [
-        { "name": "message", "type": "string" }
-      ],
-      "returns": "string",
-      "description": "Return the input message prefixed with 'echo:'."
-    },
-    {
-      "name": "shout",
-      "args": [
-        { "name": "message", "type": "string" }
-      ],
-      "returns": "string",
-      "description": "Return the input message upper-cased and prefixed with 'SHOUT:'."
-    },
-    {
-      "name": "init",
-      "args": [],
-      "returns": "void",
-      "description": "Optional setup hook — called once after install / dashboard start."
-    }
-  ],
-  "permissions": [],
-  "configSchema": {
-    "greeting": {
-      "type": "string",
-      "required": false,
-      "default": "echo"
-    }
-  },
-  "homepage": "https://github.com/DrB0rk/bizar-plugins",
-  "minBizarVersion": "4.9.0"
-}

package/templates/plugin-template/tests/plugin.test.js

@@ -1,83 +0,0 @@
-/**
- * tests/plugin.test.js
- *
- * Smoke tests for the Echo plugin template.
- *
- * These run with `node --test tests/plugin.test.js` from the
- * template folder. They exercise the plugin by loading it directly
- * through the host's `sandbox.mjs` (so the same code path that runs
- * in production is exercised here), not by re-implementing the
- * loading logic.
- *
- * If you copy this template for your own plugin, replace the
- * expectations with real ones for your plugin's behaviour.
- */
-import { test } from 'node:test';
-import assert from 'node:assert/strict';
-import { fileURLToPath } from 'node:url';
-import { dirname, resolve } from 'node:path';
-import { readFileSync } from 'node:fs';
-
-const HERE = dirname(fileURLToPath(import.meta.url));
-const TEMPLATE_ROOT = resolve(HERE, '..');
-
-test('plugin.json is valid JSON with required fields', () => {
-  const raw = readFileSync(resolve(TEMPLATE_ROOT, 'plugin.json'), 'utf8');
-  const m = JSON.parse(raw);
-  assert.equal(typeof m.id, 'string');
-  assert.ok(m.id, 'id must be non-empty');
-  assert.equal(typeof m.version, 'string');
-  assert.ok(m.version, 'version must be non-empty');
-  assert.equal(typeof m.main, 'string');
-  assert.ok(m.main, 'main must be non-empty');
-  assert.ok(Array.isArray(m.exports), 'exports must be an array');
-  assert.ok(Array.isArray(m.permissions), 'permissions must be an array');
-});
-
-test('index.js exists and is non-empty', () => {
-  const src = readFileSync(resolve(TEMPLATE_ROOT, 'index.js'), 'utf8');
-  assert.ok(src.length > 100, 'index.js should be a real file');
-  assert.match(src, /module\.exports\s*=/, 'must use module.exports');
-});
-
-test('plugin exports echo, shout, and init', async () => {
-  // We exercise the actual sandbox so this test fails if the plugin
-  // ever drifts from the host's API surface.
-  const sandboxUrl = new URL('../../../bizar-dash/src/server/plugins/sandbox.mjs',
-    import.meta.url);
-  const { loadPlugin, safeInvoke } = await import(sandboxUrl);
-  const loaded = await loadPlugin({
-    mainFile: resolve(TEMPLATE_ROOT, 'index.js'),
-    config: { greeting: 'test' },
-    permissions: [],
-    pluginId: 'echo',
-    pluginRoot: TEMPLATE_ROOT,
-  });
-  assert.equal(typeof loaded.exports.echo, 'function');
-  assert.equal(typeof loaded.exports.shout, 'function');
-  assert.equal(typeof loaded.exports.init, 'function');
-
-  const r1 = await safeInvoke(loaded, 'echo', ['hello']);
-  assert.equal(r1.ok, true);
-  assert.equal(r1.result, 'test: hello');
-
-  const r2 = await safeInvoke(loaded, 'shout', ['hi']);
-  assert.equal(r2.ok, true);
-  assert.equal(r2.result, 'SHOUT: HI');
-});
-
-test('echo validates its argument', async () => {
-  const sandboxUrl = new URL('../../../bizar-dash/src/server/plugins/sandbox.mjs',
-    import.meta.url);
-  const { loadPlugin, safeInvoke } = await import(sandboxUrl);
-  const loaded = await loadPlugin({
-    mainFile: resolve(TEMPLATE_ROOT, 'index.js'),
-    config: {},
-    permissions: [],
-    pluginId: 'echo',
-    pluginRoot: TEMPLATE_ROOT,
-  });
-  const r = await safeInvoke(loaded, 'echo', [42]);
-  assert.equal(r.ok, false);
-  assert.match(r.error, /expected string/);
-});

package/templates/schedules/daily-backup.json

@@ -1,12 +0,0 @@
-{
-  "id": "template-daily-backup",
-  "name": "Daily backup",
-  "description": "Create a backup every day at 03:00",
-  "type": "cron",
-  "schedule": "0 3 * * *",
-  "action": {
-    "type": "command",
-    "target": "bizar backup --label daily"
-  },
-  "tags": ["backup", "maintenance"]
-}

package/templates/schedules/daily-cleanup.json

@@ -1,12 +0,0 @@
-{
-  "id": "template-daily-cleanup",
-  "name": "Daily cleanup",
-  "description": "Clean up old backups and logs every day at 04:00",
-  "type": "cron",
-  "schedule": "0 4 * * *",
-  "action": {
-    "type": "command",
-    "target": "bizar backup delete --older-than 30d"
-  },
-  "tags": ["backup", "maintenance", "cleanup"]
-}

package/templates/schedules/hourly-health-check.json

@@ -1,12 +0,0 @@
-{
-  "id": "template-hourly-health",
-  "name": "Hourly health check",
-  "description": "Run bizar doctor every hour",
-  "type": "interval",
-  "schedule": "1h",
-  "action": {
-    "type": "command",
-    "target": "bizar doctor"
-  },
-  "tags": ["health", "monitoring"]
-}

package/templates/schedules/webhook-on-push.json

@@ -1,13 +0,0 @@
-{
-  "id": "template-webhook-push",
-  "name": "Webhook on push (example)",
-  "description": "Trigger a webhook on git push events",
-  "type": "cron",
-  "schedule": "0 5 * * *",
-  "action": {
-    "type": "webhook",
-    "target": "https://your-server.example.com/hook",
-    "method": "POST"
-  },
-  "tags": ["webhook", "integration"]
-}

package/templates/schedules/weekly-digest.json

@@ -1,13 +0,0 @@
-{
-  "id": "template-weekly-digest",
-  "name": "Weekly digest",
-  "description": "Generate the weekly digest every Sunday at 00:00",
-  "type": "cron",
-  "schedule": "0 0 * * 0",
-  "action": {
-    "type": "agent",
-    "target": "",
-    "prompt": "Generate the weekly digest and save to vault"
-  },
-  "tags": ["memory", "reporting"]
-}