@slycode/slycode 0.1.19 → 0.2.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@slycode/slycode",
-  "version": "0.1.19",
+  "version": "0.2.0",
   "description": "AI-powered development workspace with kanban, terminal bridge, and skill management",
   "bin": {
     "slycode": "bin/slycode.js",

package/templates/kanban-seed.json

@@ -1,5 +1,5 @@
 {
   "schemaVersion": 1,
   "cards": [],
-  "lastUpdated": "2026-03-15T06:30:37.282Z"
+  "lastUpdated": "2026-03-15T07:08:19.486Z"
 }

package/dist/store/.backups/actions/onboard.md

@@ -1,33 +0,0 @@
----
-name: onboard
-version: 1.0.0
-label: "Onboard"
-description: "Analyze and improve a backlog item, then move to design"
-group: "Card Actions"
-placement: both
-scope: global
-classes:
-  backlog: 10
----
-
-Onboard this backlog item. Analyze it, improve it, and move it to design.
-
-**First, get the full card details:**
-```bash
-sly-kanban show {{card.id}}
-```
-
-**Then do this:**
-1. Analyze the card - understand the intent from title and description
-2. Improve the title - make it clear, concise, action-oriented
-3. Rewrite the description - structure logically, capture the essential gist
-4. Set appropriate areas (run `sly-kanban areas` to see options)
-4.5 Potentially use context-priming to understand that area better
-5. Set correct type and priority
-6. Apply all changes with `sly-kanban update {{card.id}} --title "..." --description "..." --areas "..." --type ... --priority ...`
-7. Move to design: `sly-kanban move {{card.id}} design`
-
-**Then explain:**
-- What you understood the intent to be
-- What changes you made and why
-- Ask for confirmation - if I disagree, I'll tell you what to adjust

package/dist/store/.backups/actions/review.md

@@ -1,37 +0,0 @@
----
-name: review
-version: 1.0.0
-label: "Review Code"
-description: "Review the implementation for code quality"
-group: "Card Actions"
-placement: startup
-scope: global
-classes:
-  testing: 20
----
-
-{{cardContext}}
-
----
-
-## Your Task
-
-Review the implementation for this card.
-
-> Card details are provided above. If you need checklist status, notes from prior sessions, or problem IDs, run `sly-kanban show {{card.id}}` before proceeding.
-
-**Context priming:** If you haven't already, use `/context-priming` with the card's **Areas** to understand the codebase patterns and review the changes in context.
-
-**Review checklist:**
-1. Code quality and best practices
-2. Potential bugs or edge cases
-3. Performance considerations
-4. Security concerns
-5. Documentation/comments adequate?
-
-**Log any issues found:**
-```bash
-sly-kanban problem {{card.id}} add "description" --severity <minor|major|critical>
-```
-
-**Summary:** Overall assessment and any required changes before approval.

package/dist/store/.backups/actions/show-card.md

@@ -1,20 +0,0 @@
----
-name: show-card
-version: 1.0.0
-label: "Show Card"
-description: "Display full card details"
-group: "Utilities"
-placement: both
-scope: global
-classes:
-  backlog: 30
-  design: 80
-  done: 40
-  implementation: 70
-  testing: 70
----
-
-Show the full details of this card:
-```bash
-sly-kanban show {{card.id}}
-```

package/dist/store/.backups/checkpoint/SKILL.md

@@ -1,43 +0,0 @@
----
-provider: claude
-version: 1.2.0
-updated: 2026-02-01
-allowed-tools: Bash, Read
-argument-hint: [optional commit message]
-description: Create a git checkpoint of ALL recent changes
----
-
-# Git Checkpoint Creation
-
-Create a checkpoint commit of ALL uncommitted changes in the repository.
-
-## Process
-
-1. **Check status**: Run `git status --short` to see all changes
-2. **Analyze changes**: For each modified/added file, briefly review what changed using `git diff <file> | head -50` or read new files
-3. **Stage everything**: Run `git add -A` to stage ALL changes (modified, new, and deleted files)
-4. **Write commit message**: Based on analysis, write a clear commit message that:
-   - Has a concise summary line (under 72 chars)
-   - Lists key changes as bullet points
-   - Groups related changes together
-5. **Commit**: Create the commit with the message
-
-## Important Rules
-
-- **Commit EVERYTHING**: Do not selectively pick files. All uncommitted changes should be included.
-- **Analyze first**: Read diffs or file contents to understand what changed before writing the commit message.
-- **Be descriptive**: The commit message should explain WHAT was done, not just list file names.
-- **No AI attribution**: Do not include "Co-Authored-By: Claude" or similar.
-
-## Example Commit Message Format
-
-```
-Summary of changes in imperative mood
-
-- Add feature X with support for Y
-- Fix bug in Z where condition was wrong
-- Update config to enable new option
-- Refactor module for better performance
-```
-
-If an optional message argument is provided, use it as the summary line.

package/dist/store/.backups/context-priming/SKILL.md

@@ -1,153 +0,0 @@
----
-provider: claude
-name: context-priming
-version: 1.1.0
-updated: 2026-02-14
-description: Dynamic context provider for codebase knowledge. This skill should be used when working on code, answering questions about architecture, or making changes that require understanding of project structure. Maintains area-specific reference files that are loaded on demand. Self-updating based on observed drift between references and actual code. Load this skill early in work sessions - it contains essential workflow and update protocols.
----
-
-# Context Priming
-
-Provide dynamic, accurate context about this project's architecture and code. Load knowledge on demand, update when drift is observed, self-improve based on experience.
-
-## When to Invoke
-
-**Load context when:**
-- Starting work requiring codebase knowledge not in current conversation
-- Making changes to unfamiliar areas
-- Answering questions about project architecture or patterns
-- User asks about functionality and current context is insufficient
-
-**Do NOT load when:**
-- Information is clearly present from last 3-5 exchanges
-- Task is trivial and doesn't require architectural understanding
-- Already loaded relevant areas in this session (unless significant time/work has passed)
-
-## How to Use
-
-1. **Load area-index.md first** - understand available areas, their update dates, load-when triggers
-2. **Load relevant area(s)** - based on current task and index guidance
-3. **Follow area's "when to expand"** - each area indicates when to open specific files
-4. **Evaluate freshness** - compare area's `updated` date against today (from system prompt); consider git activity if concerned
-
-## Callouts
-
-Prefix operational updates with `Priming:` to signal skill activity. Keep brief - one line.
-
-**When to call out:**
-- Loading an area: `Priming: Loading backend - API work detected.`
-- Loading multiple: `Priming: This spans backend and database areas, loading both.`
-- Staleness concern: `Priming: backend looks stale (Nov 20), will verify as I go.`
-- Making a note: `Priming: Quick note added - auth order matters.`
-- Skipping load: `Priming: Already have frontend context from earlier.`
-
-**Don't call out:** Every file read, minor internal decisions, routine checks.
-
-## Update Behavior
-
-| Situation | Action |
-|-----------|--------|
-| Loaded info contradicts code in misleading way | Update reference in stride |
-| Minor drift, no practical impact | Let it slide |
-| Unsure if update needed | Note concern, ask at end of task |
-| Multiple areas need restructuring | Consult user before proceeding |
-| New feature added affecting an area | Update area reference |
-| User says "context priming needs to know this" | Capture in relevant area |
-| User says "you should have known this" | Analyze failure, propose fix (see below) |
-
-**Small updates**: Make concisely, in stride, no announcement needed.
-**Large restructuring/defrag**: Consult first. See `references/maintenance.md`.
-
-## "You Should Have Known" Response
-
-When user indicates priming failed:
-
-1. **Identify cause**: Which of these?
-   - Area not loaded when it should have been (bad load-when criteria)
-   - Area loaded but info missing (incomplete reference)
-   - Info existed but outdated (stale reference)
-   - Area doesn't exist (missing area)
-   - Judgment call to skip loading was wrong (bad heuristic)
-
-2. **Propose fix** based on cause:
-   - Content/index updates → do in stride
-   - SKILL.md or maintenance.md changes → explain problem, propose change, await approval
-
-3. **Surface immediately** - don't wait for task end. User will indicate if disruptive.
-
-## Permission Model
-
-| File | Permission |
-|------|------------|
-| references/areas/*.md | Update in stride |
-| references/area-index.md | Update in stride |
-| Add/remove/split areas | Suggest, light confirmation |
-| SKILL.md | Explain, propose, await approval |
-| references/maintenance.md | Explain, propose, await approval |
-
-## Git Usage
-
-Use `git diff` or `git log` sparingly:
-- Before major refactors to verify scope
-- When user questions accuracy of loaded info
-- To check activity since area's last update date when staleness suspected
-
-Not for routine small changes.
-
-## Context Compaction
-
-No direct visibility into remaining context space. When user flags compaction is imminent, or after long exploration sessions: consider if valuable learnings should be captured before context is summarized.
-
-## Self-Improvement
-
-Area notes (in area-index.md) capture learnings:
-- Up to 10 notes per area, quality over quantity
-- Format: actionable guidance ("when X, do Y" or "don't assume Z")
-- Remove notes that no longer apply
-- If skill behavior is flawed, suggest improvement to user
-
-If suggestion timing/frequency becomes disruptive, user will indicate - adjust accordingly.
-
-## Operational Principles
-
-- Concise updates: prefer short phrase tweaks over paragraph additions
-- Don't bloat references - information density is the goal
-- When on fence about loading, lean toward loading
-- Trust the index's load-when triggers; refine them when wrong
-- No hardcoded "status" - freshness is evaluated dynamically
-
-## Skill Location & Cross-Provider Note
-
-**Canonical path (relative to project root):**
-```
-.claude/skills/context-priming/
-├── SKILL.md                        # This file
-├── references/
-│   ├── area-index.md               # Index of all areas (load first)
-│   ├── maintenance.md              # Defrag, pruning, area separation doctrine
-│   └── areas/
-│       └── [name].md               # Deep reference per area
-```
-
-**Resolution order — try these paths in order, use the first that exists:**
-
-1. **Primary:** `<project-root>/.claude/skills/context-priming/` — the canonical, most up-to-date copy. Always check here first.
-2. **Fallback:** The directory containing this SKILL.md (i.e. your own skill folder). If there is no `.claude/` directory in the project, the references were likely copied alongside this file.
-
-This matters when the skill is deployed to another provider (Codex at `.agents/skills/`, Gemini at `.gemini/skills/`). Those folders may contain just this SKILL.md for discovery, with the area files living in `.claude/`. But if the project has no `.claude/` directory at all (e.g. a pure Codex or Gemini project), fall back to reading from your own skill directory.
-
-**Resolved paths (primary):**
-- **Area index:** `<project-root>/.claude/skills/context-priming/references/area-index.md`
-- **Area files:** `<project-root>/.claude/skills/context-priming/references/areas/<name>.md`
-- **Maintenance:** `<project-root>/.claude/skills/context-priming/references/maintenance.md`
-
-**Resolved paths (fallback — relative to this SKILL.md):**
-- **Area index:** `./references/area-index.md`
-- **Area files:** `./references/areas/<name>.md`
-- **Maintenance:** `./references/maintenance.md`
-
-## Files
-
-- `references/area-index.md` - compact index of all areas
-- `references/maintenance.md` - defrag, pruning, area separation doctrine
-- `references/areas/[name].md` - deep reference per area

package/dist/store/.backups/context-priming/references/area-index.md

@@ -1,101 +0,0 @@
-# Area Index
-
-Updated: 2026-02-14
-
-## Areas
-
-### web-frontend
-- path: areas/web-frontend.md
-- updated: 2026-02-14
-- load-when: dashboard, kanban, cards, modal, UI components, drag-drop, project page, checklist, command config, health monitor, reconnection, toolkit, assets, search, scaffolding, activity feed, keyboard shortcuts, health score, tab sync, theme, design system, colors, gradient, texture, grain, noise, logo, neon, glow, blend mode, terminal styling, dark mode, light mode, provider selector, provider dropdown
-- notes:
-  - CardModal tabs are dynamic: Details, Design?, Feature?, Test?, Checklist?, Terminal
-  - Terminal tab auto-connects when session is running
-  - HealthMonitor in ProjectHeader shows CPU/memory/terminals, expands on hover
-  - ConnectionManager handles SSE reconnection with Page Visibility API
-  - Cards with active work show pulsing green glow (active-glow-card CSS class)
-  - Commands use startupCommands (session start) and activeCommands (toolbar)
-  - ToolkitTab manages cross-project asset deployment (commands/skills/agents)
-  - HealthDot on ProjectCard shows 0-100 score (green/amber/red)
-  - paths.ts replaces all hardcoded paths with dynamic resolution
-  - CardModal has edit session protection (2000ms grace period, last-known-value tracking)
-  - Provider selector in ClaudeTerminalPanel pre-fills from stage defaults via /api/providers
-  - CardModal detects existing session's provider from session name (projectId:provider:card:cardId)
-  - NEVER use dark-end color scales for dark mode vibrant colors — use bright color at low opacity
-  - soft-light blend produces warm/red cast on dark backgrounds — use screen or overlay instead
-  - drop-shadow filters create rectangular glow on images with opaque backgrounds — incompatible with mix-blend-mode logo transparency
-  - Gradient direction: always left (vibrant) to right (soft), never center-out
-  - Texture is three layers: fine grain + perlin noise + depth highlight — each with separate light/dark tuning
-
-### terminal-bridge
-- path: areas/terminal-bridge.md
-- updated: 2026-02-14
-- load-when: terminal, Claude panel, xterm, bridge, pty, session, websocket, SSE, spawn, terminal class, security, stats, activity log, stop-all, provider, providers.json, multi-provider, gemini, codex, claude, resume, skip-permissions, YOLO
-- notes:
-  - Pass prompts as positional args to Claude CLI, NOT -p flag (-p is print mode)
-  - Bridge binds to localhost by default (not 0.0.0.0) for security
-  - Command whitelist in bridge-config.json (only 'claude' and 'bash' allowed)
-  - CWD validated before spawning PTY (must be absolute path)
-  - Activity tracking: lastOutputAt timestamp, 2s threshold for "active" status
-  - Grace period (5s) after disconnect prevents idle timeout race condition
-  - ActivityTransition logging with trigger details for debugging phantom blips
-  - Atomic state saves (temp file + rename) prevent data corruption
-  - POST /sessions/:name/stop sends Escape key (soft stop) vs DELETE (kill)
-  - Session names now include provider: {projectId}:{provider}:card:{cardId} (with legacy fallback)
-  - provider-utils.ts builds command args from providers.json config (flag vs subcommand resume)
-  - GUID detection only for Claude; Gemini/Codex use --resume --last
-
-### claude-actions
-- path: areas/claude-actions.md
-- updated: 2026-02-09
-- load-when: actions, prompts, templates, context injection, commands, visibility, command config
-- notes:
-  - Unified command system in data/commands.json (v2.0)
-  - No 'type' field on Command - filtering by class + sessionState
-  - getStartupCommands() for session start, getActiveCommands() for toolbar
-  - Session states: new, resume, active, any
-  - Groups: Card Actions, Session, Project, Utilities, Problems, Command Assistant
-  - Update Priming and Chore Plan are newer commands
-
-### messaging
-- path: areas/messaging.md
-- updated: 2026-02-14
-- load-when: telegram, messaging, voice, TTS, STT, speech, channel, bot, ElevenLabs, Whisper, voice swap, stop command, response mode, tone, command filter, provider, permission mismatch
-- notes:
-  - Channel abstraction in types.ts, Telegram is first implementation
-  - Voice pipeline: Whisper STT → ElevenLabs v3 TTS with [audio tags]
-  - sendTextRaw() bypasses Markdown (preserves [brackets] for voice tags)
-  - Chat actions for status indicators (record_voice, typing, upload_voice)
-  - Voice search queries both personal (/v2/voices) and community (/v1/shared-voices)
-  - State persisted in messaging-state.json (project + voice + responseMode + voiceTone)
-  - CLI tool used by messaging skill to send outbound messages
-  - "stop" text intercepted and sends Escape to active session (not forwarded as prompt)
-  - command-filter.ts provides context-aware command filtering with template resolution
-  - kanban-client.ts gives direct access to project card data for prompts
-  - Messaging always forces skipPermissions: true (remote can't approve prompts)
-  - Permission mismatch detection when session started from web UI without skip-permissions
-  - State persists selectedProvider alongside project/voice/mode/tone
-
-### skills
-- path: areas/skills.md
-- updated: 2026-02-09
-- load-when: skills, commands, agents, hooks, slash commands, SKILL.md, scaffolding
-- notes:
-  - Skills live in .claude/skills/, commands in .claude/commands/, agents in .claude/agents/
-  - 6 skills: context-priming, interactive-explainer, skill-creator, messaging, claude-code-docs-maintainer, kanban
-  - 1 agent: doc-updater
-  - 10 commands: checkpoint, feature, chore, implement, design, doc-discovery, doc-update, reference-fetch, create-command, problem_summary
-  - Scaffold templates in data/scaffold-templates/
-
-### scripts-deployment
-- path: areas/scripts-deployment.md
-- updated: 2026-02-10
-- load-when: setup, scripts, deployment, start, stop, restart, dev, ports, service, systemd, launchd, linger, PID, zombie, sly-start, sly-stop, sly-dev, sly-restart, setup.sh, .env, environment, production, build, tmux, bridge-sessions, XDG_RUNTIME_DIR
-- notes:
-  - Two port ranges: dev (3003/4/5) and prod (7591/2/3 = "sly" on keypad)
-  - Stop by port, NOT PID files (npm spawns children, PIDs go stale)
-  - bridge-sessions.json is critical — crash on read errors, never silently wipe
-  - XDG_RUNTIME_DIR must be set for systemctl --user in code-server
-  - Build every time on prod start — no stale build risk
-  - sly-dev.sh tmux hook calls sly-stop.sh on session close to prevent zombies
-  - Global CLIs: sly-kanban, sly-messaging, sly-scaffold (symlinked to ~/bin)

package/dist/store/.backups/context-priming/references/areas/claude-actions.md

@@ -1,120 +0,0 @@
-# Claude Actions (Commands)
-
-Updated: 2026-02-09
-
-## Overview
-
-Unified command system for Claude terminals. Commands are defined in `data/commands.json` with visibility controlled by terminal classes and session state. Commands are split into **startup commands** (shown before/during session start) and **active commands** (shown in toolbar while running).
-
-## Key Files
-
-- `data/commands.json` - Unified command definitions (prompts, visibility, groups)
-- `documentation/terminal-classes.json` - Terminal class definitions
-- `web/src/lib/claude-actions.ts` - getStartupCommands(), getActiveCommands(), renderTemplate(), buildPrompt()
-- `web/src/lib/types.ts` - Command, CommandsConfig, TerminalClass types
-- `web/src/app/api/commands/route.ts` - CRUD for commands.json
-- `web/src/app/api/commands/stream/route.ts` - SSE for file change detection
-- `web/src/app/api/terminal-classes/route.ts` - Serves terminal-classes.json
-- `web/src/app/api/claude-actions/route.ts` - Serves commands in ClaudeActionsConfig format
-
-## Data Models
-
-```typescript
-// Unified command (no 'type' field - filtering by class + sessionState)
-Command {
-  label: string;
-  description: string;
-  group?: string;           // Card Actions, Session, Project, Utilities, Problems
-  cardTypes?: string[];     // Filter: feature/bug/chore
-  prompt: string;           // Template with {{placeholders}}
-  visibleIn: {
-    classes: string[];      // Terminal classes where this appears
-    projects: string[];     // Specific projects (if scope='specific')
-  };
-  scope: 'global' | 'specific';
-  sessionState: 'new' | 'resume' | 'active' | 'any';
-}
-
-// Internal format used by ClaudeTerminalPanel
-ClaudeCommand {
-  id: string;
-  label: string;
-  description: string;
-  group?: string;
-  cardTypes?: string[];
-  prompt: string;
-  visibleIn: { classes: string[]; projects: string[] };
-  scope: 'global' | 'specific';
-  sessionState: 'new' | 'resume' | 'active' | 'any';
-}
-
-// Config format served by /api/claude-actions
-ClaudeActionsConfig {
-  version: string;
-  contextTemplate: { card: string; global: string };
-  commands: ClaudeCommand[];
-}
-```
-
-## Key Functions
-
-- `getStartupCommands(commands, terminalClass, hasHistory)` - Commands for session start (new/resume/any states)
-- `getActiveCommands(commands, terminalClass)` - Commands for toolbar while running (active/any states)
-- `renderTemplate(template, context)` - Handles {{var}}, {{#if}}, {{#each}}
-- `buildPrompt(contextTemplate, actionPrompt, context)` - Combines context + task sections
-
-## Template Syntax
-
-- `{{var}}` - Simple substitution
-- `{{obj.prop}}` - Nested property access (e.g., `{{card.title}}`)
-- `{{#if var}}...{{/if}}` - Conditional block
-- `{{#each arr}}...{{this}}...{{/each}}` - Array iteration
-
-## Context Objects
-
-Card context: `{ project, projectPath, card, stage, problems[] }`
-Global context: `{ project, projectPath }`
-
-## Command Groups
-
-- **Card Actions** - Stage-specific workflows (Onboard, Design Doc, Implement, Debug, etc.)
-- **Session** - Continue, Summarize (for resume state)
-- **Project** - Explore, New Card (for project-level terminals)
-- **Utilities** - Compact, Clear, Checkpoint, Context, Show Card
-- **Problems** - Log Problem, Triage Problems, Fix Issues
-- **Command Assistant** - Configure, Update Priming (for command-assistant terminal class)
-
-### Additional Commands
-- **Chore Plan** - Create maintenance/bug fix plan from card
-
-## Session States
-
-- `new` - No history, shown for fresh start
-- `resume` - Has history, shown when resuming (Continue, Summarize)
-- `active` - Shown in toolbar when terminal is running
-- `any` - Always shown regardless of state
-
-## Command Flow
-
-1. **No session**: Show `startupCommands` (new + any states) as buttons
-2. **Has history**: Show Resume button + `startupCommands` (new + any) for fresh start options
-3. **Running**: Show `activeCommands` (active + any states) in footer toolbar
-
-## Patterns & Invariants
-
-- Commands filtered by: terminalClass + sessionState
-- Startup commands: sessionState in ['new', 'resume', 'any'] based on hasHistory
-- Active commands: sessionState in ['active', 'any']
-- MAX_VISIBLE_ACTIONS = 6, overflow goes to "..." menu
-- Context button (id: 'context') appends card.areas to command
-- Show Card button (id: 'show-card') appends cardId
-- Shift+click on active command inserts without submitting
-
-## When to Expand
-
-- Adding new commands → data/commands.json
-- Changing filter logic → getStartupCommands/getActiveCommands in claude-actions.ts
-- Template issues → renderTemplate() in claude-actions.ts
-- UI for commands → ClaudeTerminalPanel.tsx
-- Terminal class definitions → documentation/terminal-classes.json
-- Command configuration UI → CommandConfigModal.tsx