@cubis/foundry 0.3.83 → 0.3.84

package/src/cli/workflows/commands.ts

@@ -1,163 +0,0 @@
-import type { Command } from "commander";
-import type {
-  CommandDecorator,
-  WorkflowAction,
-  WorkflowDoctorAction,
-  WorkflowTargetAction,
-} from "../types.js";
-
-export interface WorkflowCommandDeps {
-  withInstallOptions: CommandDecorator;
-  withWorkflowBaseOptions: CommandDecorator;
-  registerConfigKeysSubcommands: (configCommand: Command) => void;
-  runWorkflowInstall: WorkflowAction;
-  runWorkflowRemove: WorkflowTargetAction;
-  runWorkflowRemoveAll: WorkflowAction;
-  runWorkflowPruneSkills: WorkflowAction;
-  runWorkflowSyncRules: WorkflowAction;
-  runWorkflowDoctor: WorkflowDoctorAction;
-  runWorkflowConfig: WorkflowAction;
-  printPlatforms: () => void;
-  defaultSkillProfile: string;
-}
-
-export function registerWorkflowCommands(
-  program: Command,
-  deps: WorkflowCommandDeps,
-) {
-  const workflowsCommand = program
-    .command("workflows")
-    .description(
-      "Install and manage workflow bundles for Antigravity, Codex, Copilot, Claude, and Gemini CLI",
-    );
-
-  workflowsCommand
-    .command("platforms")
-    .description("List workflow platform ids and defaults")
-    .action(deps.printPlatforms);
-
-  deps
-    .withInstallOptions(
-      workflowsCommand
-        .command("install")
-        .description("Install a workflow bundle into the selected platform"),
-    )
-    .action(deps.runWorkflowInstall);
-
-  deps
-    .withWorkflowBaseOptions(
-      workflowsCommand
-        .command("remove <bundle-or-workflow>")
-        .description("Remove an installed bundle or workflow and sync rules")
-        .option("--dry-run", "preview remove and sync without writing files")
-        .option("-y, --yes", "skip interactive confirmation"),
-    )
-    .action(deps.runWorkflowRemove);
-
-  workflowsCommand
-    .command("remove-all")
-    .description(
-      "Remove all CBX-managed generated artifacts (workflows/agents/skills/rules/MCP config)",
-    )
-    .option(
-      "-p, --platform <platform>",
-      "target platform id or 'all' (default: all)",
-      "all",
-    )
-    .option(
-      "--scope <scope>",
-      "target scope: project|global|all (default: all)",
-      "all",
-    )
-    .option(
-      "--target <path>",
-      "remove project-scope artifacts from target project directory",
-    )
-    .option(
-      "--include-credentials",
-      "also remove ~/.cbx/credentials.env when scope includes global",
-    )
-    .option("--dry-run", "preview remove operations without writing files")
-    .option("-y, --yes", "skip interactive confirmation")
-    .action(deps.runWorkflowRemoveAll);
-
-  deps
-    .withWorkflowBaseOptions(
-      workflowsCommand
-        .command("prune-skills")
-        .description(
-          "Prune nested duplicates and out-of-profile installed skills",
-        )
-        .option(
-          "-b, --bundle <bundle>",
-          "bundle id (default: agent-environment-setup)",
-        )
-        .option(
-          "--skill-profile <profile>",
-          "skill prune profile: core|web-backend|full",
-          deps.defaultSkillProfile,
-        )
-        .option("--all-skills", "alias for --skill-profile full")
-        .option(
-          "--dry-run",
-          "preview prune operations without deleting files",
-        )
-        .option("-y, --yes", "skip interactive confirmation"),
-    )
-    .action(deps.runWorkflowPruneSkills);
-
-  deps
-    .withWorkflowBaseOptions(
-      workflowsCommand
-        .command("sync-rules")
-        .description(
-          "Rebuild the managed workflow routing block for the selected platform",
-        )
-        .option("--dry-run", "preview managed rule sync without writing files")
-        .option("--json", "output JSON"),
-    )
-    .action(deps.runWorkflowSyncRules);
-
-  deps
-    .withWorkflowBaseOptions(
-      workflowsCommand
-        .command("doctor [platform]")
-        .description(
-          "Validate workflow paths, rule file status, and managed block health",
-        )
-        .option("--json", "output JSON"),
-    )
-    .action(deps.runWorkflowDoctor);
-
-  const workflowsConfigCommand = workflowsCommand
-    .command("config")
-    .description("View or edit cbx_config.json from terminal")
-    .option(
-      "-p, --platform <platform>",
-      "target platform id for MCP target patch",
-    )
-    .option(
-      "--scope <scope>",
-      "config scope: project|workspace|global|user",
-      "global",
-    )
-    .option("--show", "show current config (default when no edit flags)")
-    .option("--edit", "edit Postman default workspace ID interactively")
-    .option("--workspace-id <id|null>", "set postman.defaultWorkspaceId")
-    .option("--clear-workspace-id", "set postman.defaultWorkspaceId to null")
-    .option(
-      "--postman-mode <mode>",
-      "set postman.mcpUrl via mode: minimal|code|full",
-    )
-    .option("--mcp-runtime <runtime>", "set mcp.runtime: docker|local")
-    .option("--mcp-fallback <fallback>", "set mcp.fallback: local|fail|skip")
-    .option("--show-after", "print JSON after update")
-    .option("--dry-run", "preview changes without writing files")
-    .action(deps.runWorkflowConfig);
-
-  deps.registerConfigKeysSubcommands(workflowsConfigCommand);
-
-  workflowsCommand.action(() => {
-    workflowsCommand.help();
-  });
-}

package/src/cli/workflows/index.ts

@@ -1 +0,0 @@
-export {};

package/tsconfig.cli.json

@@ -1,19 +0,0 @@
-{
-  "compilerOptions": {
-    "target": "ES2022",
-    "module": "NodeNext",
-    "moduleResolution": "NodeNext",
-    "lib": ["ES2022"],
-    "outDir": "dist/cli",
-    "rootDir": "src/cli",
-    "strict": false,
-    "esModuleInterop": true,
-    "skipLibCheck": true,
-    "forceConsistentCasingInFileNames": true,
-    "resolveJsonModule": true,
-    "declaration": false,
-    "sourceMap": true
-  },
-  "include": ["src/cli/**/*.ts"],
-  "exclude": ["node_modules", "dist"]
-}

package/workflows/skills/doc.md

@@ -1,177 +0,0 @@
-# Antigravity Skills
-
-> **Guide to creating and using Skills in the Antigravity Kit**
-
----
-
-## 📋 Overview
-
-While Antigravity's base models (like Gemini) are powerful generalists, they don't know your specific project context or your team's standards. Loading every rule or tool into the agent's context window leads to "tool bloat," higher costs, latency, and confusion.
-
-**Antigravity Skills** solve this through **Progressive Disclosure**. A Skill is a package of specialized knowledge that remains dormant until needed. This information is only loaded into the agent's context when your specific request matches the skill's description.
-
----
-
-## 📁 Structure and Scope
-
-Skills are folder-based packages. You can define these scopes based on your needs:
-
-| Scope         | Path                              | Description                          |
-| ------------- | --------------------------------- | ------------------------------------ |
-| **Workspace** | `<workspace-root>/.agent/skills/` | Available only in a specific project |
-
-### Skill Directory Structure
-
-```
-my-skill/
-├── SKILL.md      # (Required) Metadata & instructions
-├── scripts/      # (Optional) Python or Bash scripts
-├── references/   # (Optional) Text, documentation, templates
-└── assets/       # (Optional) Images or logos
-```
-
----
-
-## 🔍 Example 1: Code Review Skill
-
-This is an instruction-only skill; you only need to create the `SKILL.md` file.
-
-### Step 1: Create the directory
-
-```bash
-mkdir -p .agent/skills/code-review
-```
-
-### Step 2: Create SKILL.md
-
-```markdown
----
-name: code-review
-description: Reviews code changes for bugs, style issues, and best practices. Use when reviewing PRs or checking code quality.
----
-
-# Code Review Skill
-
-When reviewing code, follow these steps:
-
-## Review checklist
-
-1. **Correctness**: Does the code do what it's supposed to?
-2. **Edge cases**: Are error conditions handled?
-3. **Style**: Does it follow project conventions?
-4. **Performance**: Are there obvious inefficiencies?
-
-## How to provide feedback
-
-- Be specific about what needs to change
-- Explain why, not just what
-- Suggest alternatives when possible
-```
-
-> **Note**: The `SKILL.md` file contains metadata (name, description) at the top, followed by the instructions. The agent will only read the metadata and load the full instructions only when needed.
-
-### Try it out
-
-Create a file `demo_bad_code.py`:
-
-```python
-import time
-
-def get_user_data(users, id):
-    # Find user by ID
-    for u in users:
-        if u['id'] == id:
-            return u
-    return None
-
-def process_payments(items):
-    total = 0
-    for i in items:
-        # Calculate tax
-        tax = i['price'] * 0.1
-        total = total + i['price'] + tax
-        time.sleep(0.1)  # Simulate slow network call
-    return total
-
-def run_batch():
-    users = [{'id': 1, 'name': 'Alice'}, {'id': 2, 'name': 'Bob'}]
-    items = [{'price': 10}, {'price': 20}, {'price': 100}]
-
-    u = get_user_data(users, 3)
-    print("User found: " + u['name'])  # Will crash if None
-
-    print("Total: " + str(process_payments(items)))
-
-if __name__ == "__main__":
-    run_batch()
-```
-
-**Prompt**: `review the @demo_bad_code.py file`
-
-The Agent will automatically identify the `code-review` skill, load the information, and follow the instructions.
-
----
-
-## 📄 Example 2: License Header Skill
-
-This skill uses a reference file in the `resources/` (or `references/`) directory.
-
-### Step 1: Create the directory
-
-```bash
-mkdir -p .agent/skills/license-header-adder/resources
-```
-
-### Step 2: Create the template file
-
-**`.agent/skills/license-header-adder/resources/HEADER.txt`**:
-
-```
-/*
- * Copyright (c) 2026 YOUR_COMPANY_NAME LLC.
- * All rights reserved.
- * This code is proprietary and confidential.
- */
-```
-
-### Step 3: Create SKILL.md
-
-**`.agent/skills/license-header-adder/SKILL.md`**:
-
-```markdown
----
-name: license-header-adder
-description: Adds the standard corporate license header to new source files.
----
-
-# License Header Adder
-
-This skill ensures that all new source files have the correct copyright header.
-
-## Instructions
-
-1. **Read the Template**: Read the content of `resources/HEADER.txt`.
-2. **Apply to File**: When creating a new file, prepend this exact content.
-3. **Adapt Syntax**:
-   - For C-style languages (Java, TS), keep the `/* */` block.
-   - For Python/Shell, convert to `#` comments.
-```
-
-### Try it out
-
-**Prompt**: `Create a new Python script named data_processor.py that prints 'Hello World'.`
-
-The Agent will read the template, convert the comments to Python style, and automatically add it to the top of the file.
-
----
-
-## 🎯 Conclusion
-
-By creating Skills, you transform a general AI model into an expert for your project:
-
-- ✅ Systematize best practices
-- ✅ Adhere to code review rules
-- ✅ Automatically add license headers
-- ✅ The Agent automatically knows how to work with your team
-
-Instead of constantly reminding the AI to "remember to add the license" or "fix the commit format," now the Agent will do it automatically!

package/workflows/skills/drizzle-orm/SKILL.md

@@ -1,79 +0,0 @@
----
-name: drizzle-orm
-description: "Use when building or refactoring TypeScript data layers with Drizzle ORM: schema-as-code, relational queries, type-safe SQL, drizzle-kit migrations, and edge/serverless deployment patterns."
-license: MIT
-metadata:
-  author: cubis-foundry
-  version: "3.0"
-compatibility: Claude Code, Codex, GitHub Copilot
----
-
-# Drizzle ORM
-
-## Purpose
-
-Guide developers through production-grade Drizzle ORM usage including TypeScript-first schema definition, relational query building, type-safe SQL composition, drizzle-kit migration workflows, and deployment patterns for edge and serverless runtimes. This skill ensures type-safe, performant, and migration-safe database layers in TypeScript applications.
-
-## When to Use
-
-- Defining or refactoring Drizzle schema files with `pgTable`, `sqliteTable`, or `mysqlTable`.
-- Building relational queries with `db.query.*` API or composing type-safe SQL with `select()`.
-- Creating, reviewing, or troubleshooting drizzle-kit migration workflows.
-- Deploying Drizzle-backed APIs to edge runtimes (Cloudflare Workers, Vercel Edge, Deno Deploy).
-- Migrating from Prisma, TypeORM, or raw SQL to Drizzle ORM.
-- Tuning query performance, connection pooling, or prepared statement strategies.
-
-## Instructions
-
-1. **Confirm the target database engine and runtime before writing schema code** because Drizzle uses engine-specific schema builders (`pgTable`, `sqliteTable`, `mysqlTable`) that produce different SQL dialects, and mixing them causes build-time type errors and runtime failures.
-
-2. **Define all tables in schema files using the TypeScript-first schema API** because Drizzle derives all TypeScript types directly from schema definitions, making `typeof users.$inferSelect` and `typeof users.$inferInsert` the single source of truth for both database and application types, eliminating type drift.
-
-3. **Use `relations()` declarations for every foreign key relationship** because Drizzle's relational query API (`db.query.users.findMany({ with: { posts: true } })`) requires explicit relation definitions to function, and missing relations silently fall back to returning incomplete data.
-
-4. **Prefer the relational query API for reads that involve joins** because it generates optimized SQL with proper JOIN or subquery strategies, provides fully typed nested results, and eliminates the manual mapping layer that raw `select().from().leftJoin()` requires.
-
-5. **Use the SQL-like `select()` API for writes, aggregations, and complex WHERE clauses** because the relational query API is read-optimized and does not support `INSERT`, `UPDATE`, `DELETE`, `GROUP BY`, or subquery composition, which are core to transactional write paths.
-
-6. **Configure `drizzle-kit` with explicit `schema`, `out`, and `dialect` fields** because ambiguous configuration causes migrations to target the wrong tables or generate empty diffs, and dialect mismatch between config and schema silently produces invalid SQL.
-
-7. **Run `drizzle-kit generate` in CI to detect schema-migration drift** because developers frequently modify schema files without generating a migration, and this drift only surfaces during deployment when the database does not match the schema.
-
-8. **Use `drizzle-kit push` only for prototyping and development databases** because push applies schema changes directly without migration files, making production rollback impossible and leaving no audit trail of schema evolution.
-
-9. **Write migration files with both up and down logic when custom SQL is needed** because drizzle-kit auto-generated migrations handle schema additions but frequently miss data transformations, enum modifications, and index strategy changes that require manual intervention.
-
-10. **Scope database connections to the runtime deployment model** because Cloudflare Workers use D1 or Hyperdrive bindings, Vercel Edge uses connection strings with `@vercel/postgres`, and Node.js uses `postgres` or `better-sqlite3`, each requiring different Drizzle driver initialization.
-
-11. **Use `$inferSelect` and `$inferInsert` types instead of manually defining interfaces** because Drizzle derives these types from the schema at compile time, and manual interfaces drift from the schema as columns are added, renamed, or made nullable.
-
-12. **Use `prepared()` statements for hot-path queries** because prepared statements skip the SQL compilation step on repeated execution, reducing latency by 20-40% in high-throughput endpoints, and Drizzle's `.prepare()` method makes this a one-line optimization.
-
-13. **Validate schema changes against the target database before deploying** because Drizzle generates SQL at build time but does not validate against the live schema, so renaming a column that a deployed migration already renamed will produce a duplicate alteration error at runtime.
-
-14. **Separate read-only queries from write operations at the connection level** because read replicas, connection pooling, and edge caching all depend on clean read/write separation that Drizzle supports through multiple `drizzle()` instances.
-
-15. **Test Drizzle queries against the target database engine, not in-memory mocks** because SQLite, Postgres, and MySQL have different type coercion, JSON handling, and constraint enforcement behaviors that mocks cannot reproduce.
-
-16. **Use transactions for multi-table writes with `db.transaction()`** because Drizzle does not auto-wrap related writes in a transaction, and interleaved failures without transactions leave the database in an inconsistent state that is expensive to diagnose and repair.
-
-## Output Format
-
-Provide implementation guidance, code examples, and configuration as appropriate to the task. Include complete schema definitions, query patterns, migration scripts, and drizzle-kit configuration when the task requires them. Use TypeScript with strict mode throughout.
-
-## References
-
-| File | Load when |
-| --- | --- |
-| `references/schema-definition.md` | Defining or refactoring table schemas, column types, constraints, relations, or type inference patterns. |
-| `references/queries.md` | Writing relational queries, SQL-like queries, transactions, prepared statements, or aggregation patterns. |
-| `references/migrations.md` | Creating, reviewing, or troubleshooting drizzle-kit migrations, push vs generate workflow, or migration chain management. |
-
-## Scripts
-
-No helper scripts are required for this skill right now. Keep execution in `SKILL.md` and `references/` unless repeated automation becomes necessary.
-
-## Examples
-
-- "Help me design a Drizzle schema for a multi-tenant SaaS with Postgres"
-- "Review my drizzle-kit migration workflow for production safety"

package/workflows/skills/drizzle-orm/evals/assertions.md

@@ -1,52 +0,0 @@
-# Drizzle ORM Eval Assertions
-
-## Eval 1: Schema Definition with Relations
-
-This eval tests the ability to produce a correctly structured Drizzle ORM schema with table definitions, relations, type inference, and indexes for a multi-entity blog platform.
-
-### Assertions
-
-| # | Type     | What it checks                                  | Why it matters                                                                                       |
-|---|----------|-------------------------------------------------|------------------------------------------------------------------------------------------------------|
-| 1 | contains | `pgTable` — Correct table builder               | PostgreSQL requires pgTable. Using the wrong dialect builder produces incompatible SQL and type errors at build time. |
-| 2 | contains | `relations` — Relation declarations              | Drizzle's relational query API (db.query.*) requires explicit relation definitions. Without them, nested queries silently return incomplete data. |
-| 3 | contains | `$inferSelect` — Schema-derived types            | Manual TypeScript interfaces drift from the schema as columns change. $inferSelect and $inferInsert are the single source of truth. |
-| 4 | contains | `references` — Foreign key constraints           | Foreign keys enforce referential integrity at the database level. Relations alone only enable the query API — they do not create constraints. |
-| 5 | contains | `pgEnum` — Native PostgreSQL enum                | Post status as pgEnum enforces valid values at the database level and produces a fully typed column in TypeScript, unlike plain varchar. |
-| 6 | contains | `primaryKey` — Junction table composite key      | Many-to-many junction tables without a composite primary key allow duplicate rows, corrupting the relationship. |
-
-### What a passing response looks like
-
-- A `users` table with email, displayName, and role columns.
-- A `posts` table with title, content, and a `pgEnum` status column (draft/published/archived).
-- A `comments` table with foreign keys to posts and users.
-- A `tags` table and a `postsToTags` junction table with a composite primary key.
-- `relations()` declarations for all entities enabling nested queries.
-- `$inferSelect` and `$inferInsert` type exports for at least the main entities.
-- Indexes on foreign key columns (authorId on posts, postId on comments).
-
----
-
-## Eval 2: Migration Workflow
-
-This eval tests the ability to produce a safe drizzle-kit migration workflow including schema changes, migration generation, custom data migration, and deployment steps.
-
-### Assertions
-
-| # | Type     | What it checks                                  | Why it matters                                                                                       |
-|---|----------|-------------------------------------------------|------------------------------------------------------------------------------------------------------|
-| 1 | contains | `drizzle-kit` — Migration tool usage             | Drizzle ORM relies on drizzle-kit for migration management. Omitting it means no structured migration workflow. |
-| 2 | contains | `generate` — Migration file generation           | `drizzle-kit generate` creates versioned SQL files. Using `push` instead skips file creation and makes rollback impossible. |
-| 3 | contains | `pgEnum` — Native enum for status column         | Using pgEnum ensures the database rejects invalid status values. A plain varchar with application validation can be bypassed. |
-| 4 | contains | `transaction` — Atomic data migration            | Data migrations that update existing rows must be wrapped in transactions. Partial updates from failed migrations leave data inconsistent. |
-| 5 | contains | `default` — Default value on new column          | Adding a NOT NULL column without a default to a table with existing rows fails. Defaults ensure backward compatibility during migration. |
-
-### What a passing response looks like
-
-- A `drizzle.config.ts` with schema path, output directory, and dialect.
-- Schema changes: new `orgStatusEnum`, new `organizations` table, nullable `organizationId` on users.
-- Command sequence: `drizzle-kit generate` to create the migration file.
-- Generated SQL reviewed (CREATE TYPE, CREATE TABLE, ALTER TABLE ADD COLUMN).
-- A custom data migration script using `db.transaction()` to set all users to "active" status.
-- Command to apply: `drizzle-kit migrate`.
-- No use of `drizzle-kit push` for production.

package/workflows/skills/drizzle-orm/evals/evals.json

@@ -1,71 +0,0 @@
-[
-  {
-    "name": "drizzle-schema-definition-with-relations",
-    "description": "Validate that the skill produces correct Drizzle schema definitions with proper table builders, column types, relations, type inference, and index declarations for a multi-entity domain.",
-    "input": "Design a Drizzle ORM schema for a blog platform using PostgreSQL. The domain includes: users (email, display name, role), posts (title, content, status as draft/published/archived, author), comments (content, post, author), and tags with a many-to-many relationship to posts. Include type inference, relations, and indexes on foreign keys. Use pgTable and the relational query API conventions.",
-    "assertions": [
-      {
-        "type": "contains",
-        "value": "pgTable",
-        "description": "Tables must be defined using pgTable since the target is PostgreSQL. Using sqliteTable or mysqlTable would generate incompatible SQL."
-      },
-      {
-        "type": "contains",
-        "value": "relations",
-        "description": "Relation declarations must be present for the relational query API (db.query.*) to function. Missing relations cause incomplete query results."
-      },
-      {
-        "type": "contains",
-        "value": "$inferSelect",
-        "description": "Type inference must use $inferSelect and $inferInsert from the schema rather than manually defined interfaces, preventing type drift."
-      },
-      {
-        "type": "contains",
-        "value": "references",
-        "description": "Foreign key columns must use .references() to create database-level constraints for referential integrity."
-      },
-      {
-        "type": "contains",
-        "value": "pgEnum",
-        "description": "The post status (draft/published/archived) should use pgEnum to leverage PostgreSQL native enums for type safety at both database and TypeScript levels."
-      },
-      {
-        "type": "contains",
-        "value": "primaryKey",
-        "description": "The many-to-many junction table (posts-to-tags) must have a composite primary key to prevent duplicate associations."
-      }
-    ]
-  },
-  {
-    "name": "drizzle-migration-workflow",
-    "description": "Validate that the skill produces a correct drizzle-kit migration workflow including configuration, generation, custom data migration, and deployment safety practices.",
-    "input": "I have an existing Drizzle schema with a users table (id, email, name, created_at). I need to: (1) add a 'status' enum column (active, suspended, deleted) with default 'active', (2) add an 'organization_id' foreign key column that's nullable for now, (3) create the organizations table, and (4) write a data migration to set all existing users to 'active' status. Show the full drizzle-kit workflow: config, schema changes, generate, custom migration, and apply steps.",
-    "assertions": [
-      {
-        "type": "contains",
-        "value": "drizzle-kit",
-        "description": "The workflow must reference drizzle-kit commands (generate, migrate, or push) since drizzle-kit is the migration tool for Drizzle ORM."
-      },
-      {
-        "type": "contains",
-        "value": "generate",
-        "description": "The workflow must use drizzle-kit generate (not push) to create migration files, since push is unsafe for production databases."
-      },
-      {
-        "type": "contains",
-        "value": "pgEnum",
-        "description": "The status column must be defined as a pgEnum to leverage PostgreSQL native enums rather than plain varchar, ensuring database-level validation."
-      },
-      {
-        "type": "contains",
-        "value": "transaction",
-        "description": "The data migration must be wrapped in a transaction to ensure atomicity — partial backfills leave the database in an inconsistent state."
-      },
-      {
-        "type": "contains",
-        "value": "default",
-        "description": "The new status column must have a default value ('active') so that existing rows and future inserts without explicit status are handled correctly."
-      }
-    ]
-  }
-]