@aexol/spectral 0.8.0 → 0.8.5

package/dist/commands/serve.d.ts

@@ -0,0 +1,112 @@
+/**
+ * `spectral serve` — relay orchestration entry point.
+ *
+ * Architecture (post-Batch 2 cutover):
+ *  1. Pre-flight: `requireLogin()` — same UX as the main spawn path.
+ *  2. Pre-flight: `preflightSqlite()` — fail fast on a broken native module.
+ *  3. Open the SQLite store and construct a `SessionStreamManager`.
+ *  4. Register this machine with the backend (`ensureMachineRegistered`),
+ *     which either reuses a fresh `machine.json` or POSTs to
+ *     `/api/machines/register` and persists the issued JWT.
+ *  5. Open a single long-lived `RelayClient` to `/agent-connection` carrying
+ *     the machine JWT. Reconnects forever with backoff.
+ *  6. Until Batch 3 ships, every inbound non-pong frame is acked back as
+ *     `{kind:"ack", echo:<frame>}`. This proves the WS is bidirectional
+ *     end-to-end and gives operators a smoke check before envelope routing.
+ *  7. SIGINT/SIGTERM trigger graceful shutdown: dispose the relay (close 1000),
+ *     dispose the manager (tear down pi streams), close the store.
+ *
+ * What this module is NOT (yet):
+ *  - It does NOT translate relay envelopes into REST handler calls or WS
+ *    event broadcasts. That dispatcher is Batch 3.
+ *  - It does NOT bind any local port. The local HTTP server is gone.
+ *
+ * Flag surface:
+ *  - `--machine-name <name>` — display name used at registration time.
+ *  - `--port <n>` / `-p <n>` / `SPECTRAL_PORT` — accepted but warned-and-ignored
+ *    so users updating from the pre-relay version don't get a hard error.
+ *
+ * The exported `runServe()` returns a handle so tests can drive the relay
+ * loop in-process without spawning a subprocess. Tests inject
+ * `relayUrlOverride` + `fetchImpl` + `webSocketImpl` to point at an
+ * in-process fake backend.
+ */
+import { RelayClient } from "../relay/client.js";
+import type { BridgeFactory } from "../server/session-stream.js";
+import { SessionStreamManager } from "../server/session-stream.js";
+import { SessionStore } from "../server/storage.js";
+/**
+ * Translate a backend HTTP(S) base URL to the relay WS(S) URL.
+ * `http://x:y` → `ws://x:y/agent-connection`
+ * `https://x` → `wss://x/agent-connection`
+ */
+export declare function deriveRelayUrl(backendUrl: string): string;
+export interface ParsedServeArgs {
+    /** Optional machine display name override. */
+    machineName?: string;
+    /**
+     * Whether the user passed a deprecated `--port`/`SPECTRAL_PORT`. Surfaced
+     * so the CLI driver can emit a single, consistent warning.
+     */
+    deprecatedPort: boolean;
+}
+/**
+ * Parse the `serve` subcommand's flag surface. Manual parser, same style as
+ * `login`/`logout` (no CLI framework).
+ *
+ * Accepted:
+ *   --machine-name <name>
+ *   --machine-name=<name>
+ * Deprecated (warn, don't error):
+ *   --port <n>  /  -p <n>  /  --port=<n>
+ *
+ * Anything else throws so users notice typos.
+ */
+export declare function parseServeArgs(args: string[]): ParsedServeArgs;
+export interface RunServeOptions {
+    /** Working directory pi runs in. Defaults to homedir(). */
+    cwd?: string;
+    /** Skip SIGINT/SIGTERM handlers (tests). */
+    installSignalHandlers?: boolean;
+    /** Suppress startup banner (tests). */
+    silent?: boolean;
+    /** Override the SQLite path (tests). */
+    dbPath?: string;
+    /** Bridge factory for `SessionStreamManager` (tests). */
+    bridgeFactory?: BridgeFactory;
+    /** Display-name override (passed by `runServeCli` from `--machine-name`). */
+    machineName?: string;
+    /**
+     * Override the backend base URL. Honors `SPECTRAL_BACKEND_URL` env var
+     * when not set explicitly. Tests pass this to point at an in-process fake.
+     */
+    backendUrlOverride?: string;
+    /**
+     * Override the derived relay URL. Honors `SPECTRAL_RELAY_URL` env var when
+     * not set explicitly. Tests use this to point at an in-process WS server.
+     */
+    relayUrlOverride?: string;
+    /** Override fetch (tests, registration). */
+    fetchImpl?: typeof fetch;
+    /** Override the WebSocket constructor (tests, RelayClient). */
+    webSocketImpl?: ConstructorParameters<typeof RelayClient>[0]["webSocketImpl"];
+}
+export interface RunServeHandle {
+    /** Open store. Exposed for tests. */
+    store: SessionStore;
+    /** Manager driving pi streams. Exposed for tests. */
+    manager: SessionStreamManager;
+    /** Live relay client. Exposed for tests. */
+    relay: RelayClient;
+    /** Resolved machine id (from registration). */
+    machineId: string;
+    /** Close everything cleanly. Idempotent. */
+    close(): Promise<void>;
+}
+export declare function runServe(opts?: RunServeOptions): Promise<RunServeHandle>;
+/**
+ * CLI entry point used by `cli.ts`. Surfaces the deprecation warning for
+ * `--port`/`SPECTRAL_PORT` once, then defers to `runServe`.
+ */
+export declare function runServeCli(rawArgs: string[]): Promise<RunServeHandle>;
+//# sourceMappingURL=serve.d.ts.map

package/dist/commands/serve.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"serve.d.ts","sourceRoot":"","sources":["../../src/commands/serve.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAgCG;AAiBH,OAAO,EAAE,WAAW,EAAmB,MAAM,oBAAoB,CAAC;AAUlE,OAAO,KAAK,EAAE,aAAa,EAAc,MAAM,6BAA6B,CAAC;AAC7E,OAAO,EAAE,oBAAoB,EAAE,MAAM,6BAA6B,CAAC;AAEnE,OAAO,EAAmB,YAAY,EAAE,MAAM,sBAAsB,CAAC;AAerE;;;;GAIG;AACH,wBAAgB,cAAc,CAAC,UAAU,EAAE,MAAM,GAAG,MAAM,CAazD;AAED,MAAM,WAAW,eAAe;IAC9B,8CAA8C;IAC9C,WAAW,CAAC,EAAE,MAAM,CAAC;IACrB;;;OAGG;IACH,cAAc,EAAE,OAAO,CAAC;CACzB;AAED;;;;;;;;;;;GAWG;AACH,wBAAgB,cAAc,CAAC,IAAI,EAAE,MAAM,EAAE,GAAG,eAAe,CA6B9D;AAED,MAAM,WAAW,eAAe;IAC9B,2DAA2D;IAC3D,GAAG,CAAC,EAAE,MAAM,CAAC;IACb,4CAA4C;IAC5C,qBAAqB,CAAC,EAAE,OAAO,CAAC;IAChC,uCAAuC;IACvC,MAAM,CAAC,EAAE,OAAO,CAAC;IACjB,wCAAwC;IACxC,MAAM,CAAC,EAAE,MAAM,CAAC;IAChB,yDAAyD;IACzD,aAAa,CAAC,EAAE,aAAa,CAAC;IAC9B,6EAA6E;IAC7E,WAAW,CAAC,EAAE,MAAM,CAAC;IACrB;;;OAGG;IACH,kBAAkB,CAAC,EAAE,MAAM,CAAC;IAC5B;;;OAGG;IACH,gBAAgB,CAAC,EAAE,MAAM,CAAC;IAC1B,4CAA4C;IAC5C,SAAS,CAAC,EAAE,OAAO,KAAK,CAAC;IACzB,+DAA+D;IAC/D,aAAa,CAAC,EAAE,qBAAqB,CAAC,OAAO,WAAW,CAAC,CAAC,CAAC,CAAC,CAAC,eAAe,CAAC,CAAC;CAC/E;AAED,MAAM,WAAW,cAAc;IAC7B,qCAAqC;IACrC,KAAK,EAAE,YAAY,CAAC;IACpB,qDAAqD;IACrD,OAAO,EAAE,oBAAoB,CAAC;IAC9B,4CAA4C;IAC5C,KAAK,EAAE,WAAW,CAAC;IACnB,+CAA+C;IAC/C,SAAS,EAAE,MAAM,CAAC;IAClB,4CAA4C;IAC5C,KAAK,IAAI,OAAO,CAAC,IAAI,CAAC,CAAC;CACxB;AAED,wBAAsB,QAAQ,CAAC,IAAI,GAAE,eAAoB,GAAG,OAAO,CAAC,cAAc,CAAC,CA0RlF;AAED;;;GAGG;AACH,wBAAsB,WAAW,CAAC,OAAO,EAAE,MAAM,EAAE,GAAG,OAAO,CAAC,cAAc,CAAC,CAa5E"}

package/dist/commands/unbind.d.ts

@@ -0,0 +1,8 @@
+/**
+ * `spectral unbind` — remove the local Studio project binding.
+ *
+ * Reads `.aexol/aexol.jsonc`, reports what project was unbound, and deletes
+ * the file. Idempotent: missing binding is not an error.
+ */
+export declare function runUnbind(): Promise<void>;
+//# sourceMappingURL=unbind.d.ts.map

package/dist/commands/unbind.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"unbind.d.ts","sourceRoot":"","sources":["../../src/commands/unbind.ts"],"names":[],"mappings":"AAAA;;;;;GAKG;AASH,wBAAsB,SAAS,IAAI,OAAO,CAAC,IAAI,CAAC,CA+B/C"}

package/dist/config.d.ts

@@ -0,0 +1,49 @@
+/**
+ * Spectral configuration: persisted Aexol MCP credentials.
+ *
+ * Stored at ~/.spectral/config.json with mode 0600 (user read/write only).
+ * The directory is created with mode 0700.
+ *
+ * Keep this module zero-side-effect so it can be imported from both the
+ * CLI entry (pre-flight check) and the pi extension.
+ *
+ * `getConfigDir()` honors `SPECTRAL_CONFIG_DIR` so tests can redirect to a
+ * temporary directory without touching the real `~/.spectral`.
+ */
+export declare const DEFAULT_API_URL = "https://api.aexol.ai/mcp";
+export declare const TEAM_API_KEY_PREFIX = "sk-aexol-team-";
+export interface SpectralConfig {
+    apiUrl: string;
+    teamApiKey: string;
+    /** User JWT from OAuth login. When present, used for machine registration (owns the machine). */
+    userJwt?: string;
+}
+/**
+ * Resolve the directory used to store Spectral configuration.
+ *
+ * Honors `SPECTRAL_CONFIG_DIR` first (used by tests and CI), then falls back
+ * to `<HOMEDIR>/.spectral`. Computed lazily on every call so test-time env
+ * mutation works without re-importing the module.
+ */
+export declare function getConfigDir(): string;
+/** Path to the config JSON file. Computed lazily — see `getConfigDir`. */
+export declare function getConfigFile(): string;
+/**
+ * Backwards-compatible aliases for code that imported the old top-level
+ * constants. They eagerly resolve at import time, so they reflect the env
+ * state at startup. New code should call `getConfigDir()` / `getConfigFile()`
+ * directly so test-time env overrides take effect.
+ */
+export declare const CONFIG_DIR: string;
+export declare const CONFIG_FILE: string;
+/** Resolve the effective API URL: env wins, then stored value, then default. */
+export declare function getApiUrl(stored?: string): string;
+/** Validate the team API key prefix. The full token check happens server-side. */
+export declare function validateTeamApiKey(key: unknown): key is string;
+/** Read config; returns null if missing or malformed. Never throws. */
+export declare function readConfig(): Promise<SpectralConfig | null>;
+/** Persist config with restrictive permissions (dir 0700, file 0600). */
+export declare function writeConfig(cfg: SpectralConfig): Promise<void>;
+/** Delete config; returns true if a file was removed, false if there was nothing to remove. */
+export declare function deleteConfig(): Promise<boolean>;
+//# sourceMappingURL=config.d.ts.map

package/dist/config.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"config.d.ts","sourceRoot":"","sources":["../src/config.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;GAWG;AAMH,eAAO,MAAM,eAAe,6BAA6B,CAAC;AAC1D,eAAO,MAAM,mBAAmB,mBAAmB,CAAC;AAEpD,MAAM,WAAW,cAAc;IAC7B,MAAM,EAAE,MAAM,CAAC;IACf,UAAU,EAAE,MAAM,CAAC;IACnB,iGAAiG;IACjG,OAAO,CAAC,EAAE,MAAM,CAAC;CAClB;AAED;;;;;;GAMG;AACH,wBAAgB,YAAY,IAAI,MAAM,CAErC;AAED,0EAA0E;AAC1E,wBAAgB,aAAa,IAAI,MAAM,CAEtC;AAED;;;;;GAKG;AACH,eAAO,MAAM,UAAU,QAAiB,CAAC;AACzC,eAAO,MAAM,WAAW,QAAkB,CAAC;AAE3C,gFAAgF;AAChF,wBAAgB,SAAS,CAAC,MAAM,CAAC,EAAE,MAAM,GAAG,MAAM,CAEjD;AAED,kFAAkF;AAClF,wBAAgB,kBAAkB,CAAC,GAAG,EAAE,OAAO,GAAG,GAAG,IAAI,MAAM,CAE9D;AAED,uEAAuE;AACvE,wBAAsB,UAAU,IAAI,OAAO,CAAC,cAAc,GAAG,IAAI,CAAC,CA2BjE;AAED,yEAAyE;AACzE,wBAAsB,WAAW,CAAC,GAAG,EAAE,cAAc,GAAG,OAAO,CAAC,IAAI,CAAC,CAQpE;AAED,+FAA+F;AAC/F,wBAAsB,YAAY,IAAI,OAAO,CAAC,OAAO,CAAC,CASrD"}

package/dist/designer/guidelines.d.ts

@@ -0,0 +1,23 @@
+/**
+ * Core Design Guidelines
+ *
+ * Anti-AI-slop rules and design philosophy distilled from the Open Design
+ * project (https://github.com/nexu-io/open-design). These guidelines are
+ * injected into the LLM's context when it begins a design task to improve
+ * output quality and avoid common AI-generated design tropes.
+ */
+/** Anti-slop rules — what to avoid in AI-generated design. */
+export declare const ANTI_SLOP_RULES = "# Anti-AI-Slop Design Rules\n\nThese rules prevent the most common \"AI-generated look\" tropes. Apply them to every design artifact you produce.\n\n## Color\n- \u274C Warm beige/cream/peach/pink/orange-brown \"AI canvas\" backgrounds \u2014 unless the brand explicitly owns these colors\n- \u274C Aggressive purple-to-orange or blue-to-pink gradients on hero sections\n- \u2705 Use the design system's defined palette. Backgrounds come from the brand, not defaults.\n- \u2705 Prefer solid backgrounds. Gradients only when the design system calls for them.\n- \u2705 Dark mode systems (Linear-style) use true dark grays (#1a1a1a, #212121), not warm dark browns.\n\n## Typography\n- \u274C Inter as a default for everything \u2014 it's the \"AI font\" because it ships everywhere\n- \u274C Roboto unless the design system is Material Design\n- \u274C Fraunces, Playfair Display, or other \"AI serif\" fonts used without brand intent\n- \u274C Random font sizes \u2014 every size should come from the design system's scale\n- \u2705 Use the design system's font stack. If none specified, use system fonts (-apple-system, \"Segoe UI\")\n- \u2705 Headlines: 700-800 weight, tight line-height (1.05-1.15)\n- \u2705 Body: 400 weight, comfortable line-height (1.5-1.7)\n\n## Layout\n- \u274C Cards with a left-border color accent stripe (the #1 AI slop signature)\n- \u274C Rounded boxes everywhere \u2014 vary radius by component type\n- \u274C Three feature cards in a row with identical icon-above-title structure\n- \u274C Centered text for everything\n- \u2705 Alternate section backgrounds to create visual rhythm\n- \u2705 Vary section layouts: two-column, grid, masonry, full-width, split\n- \u2705 Use whitespace as a design element \u2014 not every gap needs a border or shadow\n\n## Content\n- \u274C Lorem ipsum or placeholder text\n- \u274C Emoji as primary iconography \u2014 use Unicode symbols or SVG icons instead\n- \u274C Filler copy: \"Our platform leverages cutting-edge AI to revolutionize your workflow\"\n- \u274C Made-up statistics: \"10x faster\", \"99.9% uptime\", \"500+ integrations\"\n- \u2705 Every word should earn its place. If a section feels empty, redesign it \u2014 don't pad it.\n- \u2705 Write concrete, specific copy. \"Syncs in 2.3 seconds\" beats \"Lightning fast\"\n- \u2705 Images: use gradient shapes or CSS art as placeholders, not gray rectangles\n\n## Components\n- \u274C Generic blue (#3B82F6 / Tailwind blue-500) buttons on every page\n- \u274C Cards with identical border-radius, padding, and shadow\n- \u274C The exact same button style for primary and secondary CTAs\n- \u2705 Primary buttons: filled with accent color. Secondary: outlined or ghost.\n- \u2705 Cards can have different treatments: some with borders, some with shadows, some flat\n- \u2705 Add hover/active states to every interactive element\n\n## Interactions\n- \u274C No hover states\n- \u274C Instant transitions\n- \u2705 Subtle hover effects: scale(1.01), shadow lift, color shift\n- \u2705 Smooth transitions: 150-300ms ease\n- \u2705 Active/pressed states for mobile touch targets\n\n## The \"Would Apple/Stripe/Linear ship this?\" Test\n\nBefore finalizing, look at your output and ask:\n1. Would this color palette work at a Fortune 500 company?\n2. Does the typography feel intentional or accidental?\n3. Does every section have a reason to exist?\n4. Would a professional designer recognize the system behind this?\n\nIf the answer to any of these is \"no\", revise.";
+/** Five-dimension self-critique framework. */
+export declare const CRITIQUE_FRAMEWORK = "# 5-Dimension Self-Critique\n\nAfter building a design artifact, run this critique against your output. Fix issues before showing the user.\n\n## Dimension 1 \u2014 Color Harmony\n- Do all colors come from the design system's palette?\n- Is the contrast ratio sufficient for readability (4.5:1 minimum for body text)?\n- Does the accent color appear with restraint (5-10% of surface area)?\n- Are there any accidental colors from browser defaults?\n\n## Dimension 2 \u2014 Typography Hierarchy\n- Is there a clear heading scale (3-4 distinct sizes)?\n- Do font sizes follow a consistent ratio (1.25 or 1.333)?\n- Is body text readable at 16px minimum (24px for slides)?\n- Are there any orphaned words or awkward line breaks?\n\n## Dimension 3 \u2014 Spacing Consistency\n- Do sections have consistent vertical padding (not random values)?\n- Is the gap rhythm consistent (all gaps are multiples of 4px or 8px)?\n- Are related elements closer together than unrelated ones?\n- Is the content width constrained (not full-width body text on desktop)?\n\n## Dimension 4 \u2014 Component Polish\n- Do all buttons have hover and active states?\n- Are form elements consistently styled?\n- Do cards have consistent internal padding?\n- Are shadows used intentionally (0-3 elevations max)?\n\n## Dimension 5 \u2014 Brand Coherence\n- Does this look like it belongs to one brand, not a patchwork?\n- Would the design system's owner recognize their brand here?\n- Is the tone consistent across all copy?\n- Does the first impression match the product category?";
+/** Core designer identity prompt — the "expert designer" persona. */
+export declare const DESIGNER_IDENTITY = "# Designer Identity\n\nYou are an expert designer working with the user as a manager. You produce design artifacts using HTML, CSS, and JavaScript. Your output is production-quality \u2014 not AI slop.\n\n## Your Medium\nHTML is your tool, but your medium varies: web designer, slide designer, prototyper, data-viz specialist, mobile-app designer. Adapt your thinking to the medium.\n\n## Your Process\n1. **Understand** \u2014 Clarify the output, fidelity, audience, constraints, and design system before writing any code.\n2. **Explore** \u2014 Read the active design system and any user-provided references. Map tokens to CSS custom properties.\n3. **Plan** \u2014 Lay out the section structure before writing components. Vocalize the system you'll use.\n4. **Build** \u2014 Write the HTML file(s). Show something early \u2014 a rough first pass beats radio silence.\n5. **Critique** \u2014 Run the 5-dimension self-critique. Fix issues.\n6. **Deliver** \u2014 Present the final artifact with a brief summary of design decisions.\n\n## Quality Standards\n- Production-grade CSS: use CSS Grid, custom properties, container queries, clamp(), text-wrap: pretty\n- Responsive: mobile-first with at least one breakpoint (768px)\n- Accessible: sufficient color contrast, focus styles, semantic HTML\n- Performant: no unnecessary dependencies, CSS-only animations when possible\n- Polished: consistent spacing, intentional typography, hover/active states\n\n## When to Push Back\n- If the user asks for something that would create AI slop, suggest alternatives\n- If a design choice contradicts the active design system, flag it\n- If the user wants decorations that don't serve the content (gratuitous gradients, emoji), advise against it";
+/** Full guidelines as a combined injection-ready string. */
+export declare function getDesignGuidelines(): string;
+/**
+ * First-turn discovery protocol.
+ * Forces the agent to ask clarifying questions before building anything.
+ * Based on Open Design's discovery.ts — the turn-based question protocol.
+ */
+export declare const DISCOVERY_PROTOCOL = "# Design Discovery Protocol\n\nYou have been asked to create a design artifact. Before writing ANY code, you MUST complete this discovery sequence first.\n\n## Turn 1 \u2014 Clarify the Brief (ALWAYS required)\n\nDo NOT read files, run bash, or write any code. Ask the user to clarify:\n\n1. **What kind of artifact?** Web prototype, landing page, slide deck, mobile app, dashboard, carousel, poster, or something else?\n2. **What design system?** If the user hasn't specified one, recommend 2-3 systems from `designer_list_systems` that fit their product category. Ask which they prefer.\n3. **What content?** What's the product name? Audience? Key message?\n4. **Any constraints?** Dark/light mode preference? Existing brand colors? Animations yes/no?\n\nFormat your response as a clean question \u2014 not a wall of questions, but a friendly prompt that invites the user to clarify these dimensions.\n\nExample:\n> I'd love to design this for you. To get the best result, could you tell me:\n> - What kind of page are we building? (landing, dashboard, mobile app, slide deck?)\n> - Is there a brand or visual direction you have in mind? If not, I can suggest a few design systems that fit.\n> - What's the product called, and who's the audience?\n> - Any specific constraints (dark mode, existing colors, no animations)?\n\n## Turn 2 \u2014 Load the Design System\n\nOnce the user clarifies:\n1. Call `designer_get_system` with the chosen system name\n2. Call `designer_get_skill` with the skill that matches the artifact type\n3. Announce: \"I'll use the [system name] design system and the [skill name] workflow. Let me map the tokens and plan the sections.\"\n\n## Turn 3 \u2014 Build\n\nNow follow the skill workflow exactly. Write the artifact file(s).";
+//# sourceMappingURL=guidelines.d.ts.map

package/dist/designer/guidelines.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"guidelines.d.ts","sourceRoot":"","sources":["../../src/designer/guidelines.ts"],"names":[],"mappings":"AAAA;;;;;;;GAOG;AAEH,8DAA8D;AAC9D,eAAO,MAAM,eAAe,w6GA6DmB,CAAC;AAEhD,8CAA8C;AAC9C,eAAO,MAAM,kBAAkB,mhDAgCyB,CAAC;AAEzD,qEAAqE;AACrE,eAAO,MAAM,iBAAiB,4sDAyBgF,CAAC;AAE/G,4DAA4D;AAC5D,wBAAgB,mBAAmB,IAAI,MAAM,CAE5C;AAMD;;;;GAIG;AACH,eAAO,MAAM,kBAAkB,quDA+BoC,CAAC"}

package/dist/designer/index.d.ts

@@ -0,0 +1,26 @@
+/**
+ * Designer Extension — Built-in Design Tools for the pi Coding Agent
+ *
+ * Brings the Open Design workflow (https://github.com/nexu-io/open-design)
+ * into the pi agent as native tools. The extension provides:
+ *
+ *   • Design system knowledge — curated palettes, typography, spacing from
+ *     Apple, Stripe, Linear, Vercel, Notion, Airbnb, and more.
+ *   • Design skill workflows — structured guides for web prototypes, SaaS
+ *     landings, slide decks, mobile apps, dashboards, and social carousels.
+ *   • Design guidelines — anti-AI-slop rules and a 5-dimension critique
+ *     framework to keep output polished.
+ *   • System prompt injection — when the user asks for design work, the
+ *     extension injects designer identity and anti-slop rules into context.
+ *
+ * Architecture:
+ *   The extension registers knowledge-retrieval tools. The LLM reads design
+ *   systems and skill workflows, then uses its existing tools (write, bash,
+ *   read) to produce design artifact files. This matches how Open Design
+ *   works: the daemon composes a system prompt, the agent does the build.
+ *
+ * No packages to install — everything is embedded in this extension.
+ */
+import type { ExtensionAPI } from "../sdk/coding-agent/index.js";
+export default function designerExtension(pi: ExtensionAPI): void;
+//# sourceMappingURL=index.d.ts.map

package/dist/designer/index.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../../src/designer/index.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;GAsBG;AAEH,OAAO,KAAK,EAAE,YAAY,EAAE,MAAM,8BAA8B,CAAC;AAmGjE,MAAM,CAAC,OAAO,UAAU,iBAAiB,CAAC,EAAE,EAAE,YAAY,GAAG,IAAI,CAkKhE"}

package/dist/designer/philosophies.d.ts

@@ -0,0 +1,33 @@
+/**
+ * Design Philosophy Registry — 20 design philosophies across 5 schools
+ *
+ * Adapted from Huashu-Design (https://github.com/alchaincyf/huashu-design).
+ * These philosophies provide a vocabulary for design direction when the user
+ * hasn't specified a concrete design system. They complement the 144 curated
+ * design systems and serve as the backbone for designer_recommend.
+ *
+ * Each philosophy includes:
+ *   - Core ethos (the "why")
+ *   - Signature traits (the "what" — concrete CSS-token-level characteristics)
+ *   - Best medium (HTML, AI-generated, or Hybrid)
+ *   - Scene affinity (which content types it shines for)
+ *   - Anti-patterns (what would violate this philosophy)
+ */
+export interface DesignPhilosophy {
+    name: string;
+    school: string;
+    schoolIcon: string;
+    designer: string;
+    ethos: string;
+    description: string;
+    traits: string[];
+    keywords: string[];
+    bestMedium: "html" | "ai-generated" | "hybrid";
+    sceneAffinity: string[];
+    antiPatterns: string[];
+}
+export declare const DESIGN_PHILOSOPHIES: DesignPhilosophy[];
+export declare function findPhilosophy(name: string): DesignPhilosophy | undefined;
+export declare function formatPhilosophyForLLM(p: DesignPhilosophy): string;
+export declare function listPhilosophiesForLLM(): string;
+//# sourceMappingURL=philosophies.d.ts.map

package/dist/designer/philosophies.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"philosophies.d.ts","sourceRoot":"","sources":["../../src/designer/philosophies.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;GAcG;AAEH,MAAM,WAAW,gBAAgB;IAC/B,IAAI,EAAE,MAAM,CAAC;IACb,MAAM,EAAE,MAAM,CAAC;IACf,UAAU,EAAE,MAAM,CAAC;IACnB,QAAQ,EAAE,MAAM,CAAC;IACjB,KAAK,EAAE,MAAM,CAAC;IACd,WAAW,EAAE,MAAM,CAAC;IACpB,MAAM,EAAE,MAAM,EAAE,CAAC;IACjB,QAAQ,EAAE,MAAM,EAAE,CAAC;IACnB,UAAU,EAAE,MAAM,GAAG,cAAc,GAAG,QAAQ,CAAC;IAC/C,aAAa,EAAE,MAAM,EAAE,CAAC;IACxB,YAAY,EAAE,MAAM,EAAE,CAAC;CACxB;AAED,eAAO,MAAM,mBAAmB,EAAE,gBAAgB,EAolBjD,CAAC;AAMF,wBAAgB,cAAc,CAAC,IAAI,EAAE,MAAM,GAAG,gBAAgB,GAAG,SAAS,CAMzE;AAMD,wBAAgB,sBAAsB,CAAC,CAAC,EAAE,gBAAgB,GAAG,MAAM,CAoClE;AAED,wBAAgB,sBAAsB,IAAI,MAAM,CA6C/C"}

package/dist/designer/skills.d.ts

@@ -0,0 +1,27 @@
+/**
+ * Embedded Design Skill Workflows
+ *
+ * Each skill is a structured workflow that guides the LLM through producing
+ * a specific kind of design artifact. Skills are based on the Open Design
+ * project (https://github.com/nexu-io/open-design).
+ *
+ * The LLM reads the skill workflow, then uses its existing tools (write, read,
+ * bash) to produce output files in the working directory.
+ */
+export interface DesignSkill {
+    name: string;
+    scenario: string;
+    description: string;
+    /** What kind of artifact this produces */
+    outputKind: "html" | "html-multi" | "slides";
+    /** The full workflow guide for the LLM */
+    workflow: string;
+}
+export declare const DESIGN_SKILLS: DesignSkill[];
+/** Lookup a skill by name (case-insensitive). */
+export declare function findSkill(name: string): DesignSkill | undefined;
+/** Format a skill workflow as markdown for the LLM. */
+export declare function formatSkillForLLM(skill: DesignSkill): string;
+/** List all skills as compact markdown. */
+export declare function listSkillsForLLM(): string;
+//# sourceMappingURL=skills.d.ts.map

package/dist/designer/skills.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"skills.d.ts","sourceRoot":"","sources":["../../src/designer/skills.ts"],"names":[],"mappings":"AAAA;;;;;;;;;GASG;AAEH,MAAM,WAAW,WAAW;IAC1B,IAAI,EAAE,MAAM,CAAC;IACb,QAAQ,EAAE,MAAM,CAAC;IACjB,WAAW,EAAE,MAAM,CAAC;IACpB,0CAA0C;IAC1C,UAAU,EAAE,MAAM,GAAG,YAAY,GAAG,QAAQ,CAAC;IAC7C,0CAA0C;IAC1C,QAAQ,EAAE,MAAM,CAAC;CAClB;AAED,eAAO,MAAM,aAAa,EAAE,WAAW,EAunDtC,CAAC;AAEF,iDAAiD;AACjD,wBAAgB,SAAS,CAAC,IAAI,EAAE,MAAM,GAAG,WAAW,GAAG,SAAS,CAM/D;AAED,uDAAuD;AACvD,wBAAgB,iBAAiB,CAAC,KAAK,EAAE,WAAW,GAAG,MAAM,CAE5D;AAED,2CAA2C;AAC3C,wBAAgB,gBAAgB,IAAI,MAAM,CAYzC"}

package/dist/designer/systems.d.ts

@@ -0,0 +1,36 @@
+/**
+ * Design System Registry — 150+ Curated Systems from Open Design
+ *
+ * Design systems are stored as DESIGN.md + tokens.css files under
+ * data/systems/<name>/. At import time, we scan the directory and
+ * parse each system's metadata (name, category, description) from
+ * the DESIGN.md frontmatter. Full content is lazily loaded on first
+ * access and cached.
+ *
+ * The tool interface remains the same as the original systems.ts:
+ *   findSystem(name)  → DesignSystem | undefined
+ *   formatSystemForLLM(system) → string
+ *   listSystemsForLLM() → string
+ */
+export interface DesignSystem {
+    name: string;
+    category: string;
+    description: string;
+    /** DESIGN.md contents (full markdown) */
+    designMd: string;
+    /** tokens.css contents (CSS custom properties) */
+    tokensCss: string;
+    /** components.html contents (component examples), if available */
+    componentsHtml: string;
+}
+export declare function findSystem(name: string): DesignSystem | undefined;
+/**
+ * Format a single design system for the LLM.
+ * Concatenates the DESIGN.md and tokens.css for a complete picture.
+ */
+export declare function formatSystemForLLM(system: DesignSystem): string;
+/**
+ * List all available design systems as a compact markdown table for the LLM.
+ */
+export declare function listSystemsForLLM(): string;
+//# sourceMappingURL=systems.d.ts.map

package/dist/designer/systems.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"systems.d.ts","sourceRoot":"","sources":["../../src/designer/systems.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;GAaG;AAYH,MAAM,WAAW,YAAY;IAC3B,IAAI,EAAE,MAAM,CAAC;IACb,QAAQ,EAAE,MAAM,CAAC;IACjB,WAAW,EAAE,MAAM,CAAC;IACpB,yCAAyC;IACzC,QAAQ,EAAE,MAAM,CAAC;IACjB,kDAAkD;IAClD,SAAS,EAAE,MAAM,CAAC;IAClB,kEAAkE;IAClE,cAAc,EAAE,MAAM,CAAC;CACxB;AA+ID,wBAAgB,UAAU,CAAC,IAAI,EAAE,MAAM,GAAG,YAAY,GAAG,SAAS,CAajE;AAMD;;;GAGG;AACH,wBAAgB,kBAAkB,CAAC,MAAM,EAAE,YAAY,GAAG,MAAM,CA0B/D;AAED;;GAEG;AACH,wBAAgB,iBAAiB,IAAI,MAAM,CA0C1C"}

package/dist/extensions/aexol-mcp.d.ts

@@ -0,0 +1,25 @@
+/**
+ * Aexol MCP pi extension.
+ *
+ * Loaded by the spectral wrapper via `--extension <abs-path>`. On startup it:
+ *   1. Reads ~/.spectral/config.json (writen by `spectral login`).
+ *   2. Calls tools/list against the MCP backend once.
+ *   3. Reads the local Studio binding (`.aexol/aexol.jsonc`) so remote tools
+ *      auto-inherit `teamId` / `projectId` without needing `remote_set_context`.
+ *   4. Registers every returned remote tool through pi.registerTool() so the
+ *      model can call them like built-in tools.
+ *   5. Registers local binding-management tools (`local_bind_project`,
+ *      `local_unbind_project`, `local_get_binding`) so users can bind a
+ *      directory to an Aexol Studio project from within the agent.
+ *
+ * Each registered tool is just a thin proxy: when pi's model invokes it, we
+ * translate the call into a JSON-RPC tools/call POST and unwrap the response
+ * into the `{ content: [{ type: "text", text }], details }` shape pi expects.
+ *
+ * Failure modes are intentionally non-fatal: if config is missing or the
+ * backend is unreachable we log a warning and return, leaving pi to start
+ * without Aexol tools rather than crashing the whole agent.
+ */
+import type { ExtensionAPI } from "../sdk/coding-agent/index.js";
+export default function aexolMcpExtension(pi: ExtensionAPI): Promise<void>;
+//# sourceMappingURL=aexol-mcp.d.ts.map

package/dist/extensions/aexol-mcp.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"aexol-mcp.d.ts","sourceRoot":"","sources":["../../src/extensions/aexol-mcp.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;GAqBG;AAEH,OAAO,KAAK,EAAE,YAAY,EAAkB,MAAM,8BAA8B,CAAC;AAqFjF,wBAA8B,iBAAiB,CAAC,EAAE,EAAE,YAAY,GAAG,OAAO,CAAC,IAAI,CAAC,CA6P/E"}

package/dist/extensions/kanban-bridge.d.ts

@@ -0,0 +1,24 @@
+/**
+ * Kanban Bridge pi extension.
+ *
+ * Registers kanban management tools that allow the coding agent to read,
+ * create, update, and move Kanban tasks on the Aexol Studio board. This
+ * enables task-driven execution — the agent can pick up TODO tasks, work
+ * on them, and move them to DONE.
+ *
+ * Auth is read from ~/.spectral/config.json (same as aexol-mcp).
+ * The Studio project ID comes from the local binding (.aexol/aexol.jsonc),
+ * falling back to an explicit kanban_project_id flag.
+ *
+ * Registered tools:
+ *   - kanban_list          — List all Kanban tasks for the project
+ *   - kanban_get           — Get a single task by ID
+ *   - kanban_create        — Create a new Kanban task
+ *   - kanban_update        — Update a task (title, description, priority, tags)
+ *   - kanban_move          — Move a task between columns (BACKLOG → TODO → IN_PROGRESS → DONE)
+ *   - kanban_next          — Pick the next TODO task and mark it IN_PROGRESS
+ *   - kanban_delete        — Delete a task
+ */
+import type { ExtensionAPI } from "../sdk/coding-agent/index.js";
+export default function kanbanBridgeExtension(pi: ExtensionAPI): Promise<void>;
+//# sourceMappingURL=kanban-bridge.d.ts.map

package/dist/extensions/kanban-bridge.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"kanban-bridge.d.ts","sourceRoot":"","sources":["../../src/extensions/kanban-bridge.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;GAoBG;AAEH,OAAO,KAAK,EAAE,YAAY,EAAkB,MAAM,8BAA8B,CAAC;AAixBjF,wBAA8B,qBAAqB,CAAC,EAAE,EAAE,YAAY,GAAG,OAAO,CAAC,IAAI,CAAC,CAiCnF"}