@archetypeai/ds-cli 0.9.1 → 0.10.0

package/files/rules/components.md

@@ -1,251 +0,0 @@
----
-paths:
-  - '**/components/**/*.svelte'
-  - '$lib/**/*.svelte'
-  - '**/custom/**/*.svelte'
----
-
-# Component Authoring Rules
-
-## Props Pattern
-
-Every component should destructure props using `$props()` with this standard pattern:
-
-```svelte
-<script>
-  import { cn } from '$lib/utils.js';
-
-  let { ref = $bindable(null), class: className, children, ...restProps } = $props();
-</script>
-```
-
-Key points:
-
-- `ref = $bindable(null)` - enables parent to bind to DOM element
-- `class: className` - rename to avoid reserved word conflict
-- `children` - snippet for slot content
-- `...restProps` - capture remaining props for spreading
-
-## data-slot Attributes
-
-Add `data-slot` to root elements for identification and styling hooks:
-
-```svelte
-<div bind:this={ref} data-slot="card" class={cn('bg-card ...', className)} {...restProps}>
-  {@render children?.()}
-</div>
-```
-
-This enables parent styling like `*:data-[slot=card]:p-4`.
-
-## Class Merging with cn()
-
-Always use `cn()` for class composition - never raw string concatenation:
-
-```svelte
-<!-- Correct -->
-<div class={cn('bg-card text-card-foreground', className)}>
-
-<!-- Wrong -->
-<div class={`bg-card text-card-foreground ${className}`}>
-```
-
-`cn()` uses clsx + tailwind-merge to properly handle class conflicts.
-
-## bits-ui Wrapper Pattern
-
-When wrapping bits-ui primitives, import the primitive and wrap it:
-
-```svelte
-<script>
-  import { Select as SelectPrimitive } from 'bits-ui';
-  import { cn } from '$lib/utils.js';
-
-  let { ref = $bindable(null), class: className, children, ...restProps } = $props();
-</script>
-
-<SelectPrimitive.Trigger
-  bind:ref
-  data-slot="select-trigger"
-  class={cn('border-input bg-transparent ...', className)}
-  {...restProps}
->
-  {@render children?.()}
-</SelectPrimitive.Trigger>
-```
-
-For the full component catalog with import paths, read `ds-manifest.json` at the project root (see `@skills/build-component`).
-
-## tailwind-variants (tv)
-
-Define variants in `<script module>` for reuse and export:
-
-```svelte
-<script module>
-  import { cn } from '$lib/utils.js';
-  import { tv } from 'tailwind-variants';
-
-  export const buttonVariants = tv({
-    base: 'inline-flex items-center justify-center rounded-md text-sm font-medium transition-colors',
-    variants: {
-      variant: {
-        default: 'bg-primary text-primary-foreground hover:bg-primary/90',
-        destructive: 'bg-destructive text-white hover:bg-destructive/90',
-        outline: 'border bg-background hover:bg-accent',
-        secondary: 'bg-secondary text-secondary-foreground hover:bg-secondary/80',
-        ghost: 'hover:bg-accent hover:text-accent-foreground',
-        link: 'text-primary underline-offset-4 hover:underline'
-      },
-      size: {
-        default: 'h-9 px-4 py-2',
-        sm: 'h-8 px-3 rounded-md',
-        lg: 'h-10 px-6 rounded-md',
-        icon: 'size-9'
-      }
-    },
-    defaultVariants: {
-      variant: 'default',
-      size: 'default'
-    }
-  });
-</script>
-
-<script>
-  let { variant = 'default', size = 'default', class: className, ...restProps } = $props();
-</script>
-
-<button class={cn(buttonVariants({ variant, size }), className)} {...restProps}>
-  {@render children?.()}
-</button>
-```
-
-## Snippet Slots
-
-Use `{@render}` for slot content:
-
-```svelte
-<!-- Default slot -->
-{@render children?.()}
-
-<!-- Named snippets (passed as props) -->
-{#snippet icon()}
-  <ChevronDown />
-{/snippet}
-
-<Button {icon}>Click me</Button>
-
-<!-- In component, render the snippet prop -->
-{@render icon?.()}
-```
-
-## restProps Spreading
-
-Always spread `...restProps` on the root element to pass through attributes:
-
-```svelte
-<button
-  bind:this={ref}
-  data-slot="button"
-  class={cn(buttonVariants({ variant, size }), className)}
-  {type}
-  {disabled}
-  {...restProps}
->
-  {@render children?.()}
-</button>
-```
-
-## Conditional Rendering
-
-Use standard Svelte `{#if}` blocks for conditional content:
-
-```svelte
-{#if href}
-  <a bind:this={ref} data-slot="button" {href} {...restProps}>
-    {@render children?.()}
-  </a>
-{:else}
-  <button bind:this={ref} data-slot="button" {...restProps}>
-    {@render children?.()}
-  </button>
-{/if}
-```
-
-## Icon Handling
-
-Icons from Lucide use consistent sizing classes:
-
-```svelte
-<script>
-  import ChevronDownIcon from '@lucide/svelte/icons/chevron-down';
-</script>
-
-<ChevronDownIcon class="size-4 opacity-50" />
-```
-
-Default icon sizing in buttons: `[&_svg:not([class*='size-'])]:size-4`
-
-## Example: Complete Card Component
-
-```svelte
-<script>
-  import { cn } from '$lib/utils.js';
-
-  let { ref = $bindable(null), class: className, children, ...restProps } = $props();
-</script>
-
-<div
-  bind:this={ref}
-  data-slot="card"
-  class={cn(
-    'bg-card text-card-foreground flex flex-col gap-6 rounded-md border py-6 shadow-sm',
-    className
-  )}
-  {...restProps}
->
-  {@render children?.()}
-</div>
-```
-
-## Example: Dialog Content with bits-ui
-
-```svelte
-<script>
-  import { Dialog as DialogPrimitive } from 'bits-ui';
-  import DialogPortal from './dialog-portal.svelte';
-  import XIcon from '@lucide/svelte/icons/x';
-  import * as Dialog from './index.js';
-  import { cn } from '$lib/utils.js';
-
-  let {
-    ref = $bindable(null),
-    class: className,
-    portalProps,
-    children,
-    showCloseButton = true,
-    ...restProps
-  } = $props();
-</script>
-
-<DialogPortal {...portalProps}>
-  <Dialog.Overlay />
-  <DialogPrimitive.Content
-    bind:ref
-    data-slot="dialog-content"
-    class={cn(
-      'bg-background fixed top-[50%] left-[50%] z-50 w-full max-w-lg translate-x-[-50%] translate-y-[-50%] rounded-lg border p-6 shadow-lg',
-      'data-[state=open]:animate-in data-[state=closed]:animate-out',
-      className
-    )}
-    {...restProps}
-  >
-    {@render children?.()}
-    {#if showCloseButton}
-      <DialogPrimitive.Close class="absolute end-4 top-4 rounded-xs opacity-70 hover:opacity-100">
-        <XIcon />
-        <span class="sr-only">Close</span>
-      </DialogPrimitive.Close>
-    {/if}
-  </DialogPrimitive.Content>
-</DialogPortal>
-```

package/files/rules/design-principles.md

@@ -1,71 +0,0 @@
----
-paths:
-  - '**/*.svelte'
-  - '**/+page.svelte'
----
-
-# Physical AI Design Principles
-
-## Scope
-
-This design system targets the **Measure** and **Reason** layers of the Physical AI stack. Interfaces built with it should support **augmentation** (helping humans perceive the physical world) and **dialogue** (helping humans reason about it). Operation and cooperation — where AI takes action in the world — are out of scope currently but will become relevant in the future.
-
-## The Physical AI Stack
-
-Physical AI capabilities form a dependency stack where each layer builds on the one below:
-
-1. **Interpret** — Make the physical world legible by surfacing signals, anomalies, and structures from sensor data
-2. **Reason** — Enable shared reasoning between humans and AI: explore hypotheses, compare alternatives, support decisions
-3. **Operate** — Delegated action: human sets intent, system executes within defined boundaries (future scope)
-4. **Co-operate** — Joint action: shared agency through mutual adjustment between humans and AI (future scope)
-
-## Agency
-
-### Human Agency Comes First
-
-At the Measure layer, the AI augments human perception — it surfaces what would otherwise remain invisible. The human retains full responsibility to interpret and act. Interfaces should present information without prescribing conclusions.
-
-At the Reason layer, interaction is dialogic. The AI contributes explanations and comparisons, but the human drives inquiry and judgment. Interfaces should enable exploration, not deliver verdicts.
-
-At the Operate layer, humans shift from direct control to goal-setting and supervision. The AI executes within defined boundaries, and responsibility becomes distributed. Interfaces should make intent, constraints, and system behavior transparent.
-
-At the Co-operate layer, humans and AI act as coordinated participants. Action is jointly negotiated, and intent, context, and responsibility are shared and continuously adjusted. Interfaces should support mutual awareness and fluid handoffs.
-
-### Interaction Is Situated
-
-Interaction unfolds within a three-way relationship: **person, system, and physical world**. Meaning arises from how sensor data, context, and human intent come together in a specific place and moment. Interfaces must maintain this connection to the physical context being observed — sensor sources, locations, time ranges, environmental conditions. Do not abstract away the situational grounding.
-
-## Design Implications
-
-### Make the World Legible
-
-- Prioritize data clarity: visualizations should reveal structure in sensor data — trends, anomalies, distributions, correlations
-- Use semantic tokens (e.g. `text-atai-good`, `text-atai-warning`, `text-atai-critical`) to communicate meaningful states, not for decorative emphasis
-- Design for continuous monitoring: prefer dashboards and live views over static reports
-
-### Support Dialogue, Not Monologue
-
-- Provide entry points for inquiry: interfaces should invite questions, comparisons, and hypothesis exploration
-- Frame AI output as contribution, not conclusion — use language and layout that position AI reasoning as input to human judgment
-- Enable iterative refinement: conversational flows, follow-up exploration, adjustable parameters
-
-### Preserve Physical Context
-
-- Show provenance: which sensors, what time range, what conditions produced the data being displayed
-- Ground abstract representations in physical reality — link charts to sensor locations, timestamps to real events
-- Consider operational environments: interfaces may be used in the field, not only at a desk
-
-### Respect the Stack Boundary
-
-- Default to interfaces that support perception and reasoning rather than autonomous AI action
-- Where possible, distinguish between "the system shows" (Measure) and "the system suggests" (Reason)
-- Prefer framing AI output as observations or suggestions rather than commands or decisions
-
-## Aesthetic Conventions
-
-### Typography
-- Use mono font (`font-mono`) with careful consideration: prefer it on badges, buttons, card headers, and numeric values. Do not apply mono to body text or descriptions.
-
-### Card Defaults
-- For single-purpose card components (status display, score, chart), use BackgroundCard as the default container.
-- Status cards showing a single metric or state often do not need a CardHeader — omit when content is self-explanatory.

package/files/rules/frontend-architecture.md

@@ -1,86 +0,0 @@
----
-paths:
-  - '**/routes/**/*.svelte'
-  - '**/+page.svelte'
-  - '**/+layout.svelte'
----
-
-# Frontend Architecture
-
-When building a page that involves more than a simple static layout, decompose it into components rather than writing a monolithic `+page.svelte`.
-
-## When to extract a component
-
-Extract a component when a section of UI has:
-
-- 3+ primitives composed together (Card + Badge + Button = a status card)
-- Its own reactive state (`$state`, `$derived`)
-- Potential for reuse across pages or skills
-
-Common extraction candidates: media inputs, status displays, result/summary views, streaming logs, file upload flows.
-
-## Gold-standard references
-
-The labs package ships composite components that demonstrate these conventions. Study their source (registry URLs in `ds-manifest.json`) before building new ones:
-
-- `video-player` (labs) — media playback with controls, composes console Card + Button with labs AspectRatio + Slider
-- `menubar` (labs) — branded header with snippet slots, composes console Button + the theme `darkMode` store
-- `sensor-chart` / `scatter-chart` (labs) — chart cards with typed data/axis config
-
-Check `ds-manifest.json` for an existing component that fits before building a new one. Use `@skills/build-component` to create new components that follow these same conventions.
-
-## Directory structure
-
-Components come from the npm packages by default — most projects need no local copies at all.
-
-```
-$lib/components/ui/
-  custom/       — project-specific components composed from the packages
-  <name>/       — registry-installed editable source (only for deliberately modified components)
-```
-
-Place custom components (ones you create for this project) in `$lib/components/ui/custom/`. Never edit anything in `node_modules`, and never put custom components next to registry-installed source.
-
-## Component conventions
-
-Follow `@rules/components` for the full conventions. The essentials:
-
-- `let { class: className, ...restProps } = $props();`
-- `cn()` for all class merging — never raw string concatenation
-- `$derived` for computed state
-- Spread `...restProps` on the root element
-- Compose from DS package components (Card, Badge, Button, etc.) — not raw HTML
-
-## Page-level orchestration
-
-`+page.svelte` is the orchestrator. It should:
-
-- Own flow state (status, session IDs, error messages)
-- Import and compose child components
-- Pass data down via props
-- Handle top-level layout (using `@skills/create-dashboard` for dashboard layouts)
-
-Components should be presentational where possible — receive data via props, emit events up.
-
-## API and streaming logic extraction
-
-SSE consumers, fetch wrappers, polling loops, and data transforms belong in a utility file, not inline in components or pages:
-
-```
-src/lib/api/activity-monitor.js   — SSE + session management
-src/lib/api/machine-state.js      — streaming + windowing
-```
-
-This keeps components focused on rendering and makes API logic testable and reusable.
-
-## Streaming UI
-
-For skills that stream results (SSE, polling), prefer:
-
-- Progressive rendering — show results as they arrive, don't wait for completion
-- Live counters or progress indicators
-- Auto-scrolling log views
-
-## Override clause
-
-If the user explicitly requests a single-file prototype, a minimal example, or specifies a different structure, follow their instruction. These guidelines apply to production-quality demos, not quick experiments.

package/files/rules/linting.md

@@ -1,31 +0,0 @@
-# Linting & Formatting
-
-## Commands
-
-| Command                | Description                      |
-| ---------------------- | -------------------------------- |
-| `npm run lint`         | Check for linting errors         |
-| `npm run lint:fix`     | Auto-fix linting errors          |
-| `npm run format`       | Format all files with Prettier   |
-| `npm run format:check` | Check formatting without changes |
-
-## Stack
-
-- **ESLint** - Flat config (v9+) with `eslint-plugin-svelte`
-- **Prettier** - Code formatting
-- **prettier-plugin-svelte** - Svelte file formatting
-- **prettier-plugin-tailwindcss** - Auto-sorts Tailwind classes
-
-## Workflow
-
-Run linting and formatting before committing:
-
-```bash
-npm run lint:fix && npm run format
-```
-
-Or check without auto-fixing:
-
-```bash
-npm run lint && npm run format:check
-```