@aifabrix/builder 2.52.1 → 2.53.1

package/.cursor/rules/deploy-rules/docker-image-ip-policy.mdc

@@ -1,49 +0,0 @@
----
-description: Builder-api and platform app Docker image IP policy — staging, explicit COPY, content gate
-globs:
-  - builder/builder-api/Dockerfile
-  - templates/applications/builder-api/Dockerfile
-  - .dockerignore
-  - scripts/stage_builder_api_for_docker.js
-  - scripts/docker_image_content_gate.js
-  - lib/build/builder-api-docker-staging.js
-alwaysApply: false
----
-
-# Docker image IP policy (builder-api)
-
-Customer-pullable **builder-api** images must contain **runtime orchestration only**, not the full Builder CLI monorepo.
-
-## Required pattern (builder-api)
-
-1. **Deny by default** — repo-root `.dockerignore` excludes dev trees from build context.
-2. **Stage on host** — `node scripts/stage_builder_api_for_docker.js` (also via `aifabrix build builder-api`) writes `docker-builder-api-staging/`.
-3. **Explicit COPY** — `builder/builder-api/Dockerfile` copies staging output only; never `COPY lib ./lib` or `COPY . .`.
-4. **Prove it** — `node scripts/docker_image_content_gate.js <image> builder-api` must pass before ACR push.
-5. **Non-root** — container runs as `appuser` (or documented service user).
-6. **No agent ACR build** — see `acr-build-restrictions.mdc` in miso builder rules; user runs registry build/push.
-
-## SSOT files
-
-| File | Role |
-| ---- | ---- |
-| `builder/builder-api/Dockerfile` | Canonical image definition |
-| `templates/applications/builder-api/Dockerfile` | Published via `npm run sync-json` only |
-| `scripts/stage_builder_api_for_docker.js` | Runtime allowlist + manifest |
-| `scripts/docker_image_content_gate.js` | Post-build forbidden-path gate |
-| `.dockerignore` | Build context hardening |
-
-## Forbidden in builder-api images
-
-- `/app/.cursor`, `/app/builder`, `/app/integration`, `/app/tests`, `/app/docs`, `/app/scripts`, `/app/packages`
-- `/app/bin/aifabrix.js` (full CLI entry)
-- `/app/templates/*` except `templates/openapi/` and `templates/external-system/` (runtime wizard/ReDoc only)
-- `*.md` under `/app/lib/`
-
-## Dev-reload
-
-`aifabrix run builder-api --reload` bind-mounts source for local dev. Image hardening applies to **production/ACR** builds only.
-
-## When changing runtime imports
-
-If `lib/programmatic/` or its transitive requires change, re-run staging manifest tests (`tests/scripts/stage_builder_api_for_docker.test.js`) and rebuild the image gate.

package/.cursor/rules/docs-rules.mdc

@@ -1,32 +0,0 @@
----
-alwaysApply: true
----
-# Documentation Rules – CLI User Docs
-
-## Audience
-
-Documents under **docs/** (including **docs/commands/**) are **public CLI user documentation**. The audience is people who use the AI Fabrix Builder CLI or integrate it into workflows—they may **not** have access to private monorepos (dataplane, miso-controller, internal plans). They do not need to know how the CLI talks to the Controller or Dataplane over HTTP.
-
-## Do Not Include in CLI User Docs
-
-- **Links or paths into other product repos (FORBIDDEN)** – No markdown links, examples, or prerequisites that point at private/sibling repositories or their trees: `../../../aifabrix-dataplane/...`, `../../aifabrix-miso/...`, `packages/miso-controller/...`, `integration/<fixture>/README.md` in another repo, `.cursor/plans/` anywhere, `/workspace/...` monorepo layouts, or “see the dataplane/miso-controller repo”. **Only** cross-link within **`docs/`** and use on-disk paths the user owns (`integration/<systemKey>/...`, `builder/<appKey>/...`, `~/.aifabrix/...`).
-- **Internal plan or ticket IDs** – No “Plan 407.1”, “plan section 2.3”, or similar; describe behavior in user terms.
-- **REST API details** – No HTTP methods, URL paths, or endpoint names (e.g. `GET /api/v1/...`, `POST .../pipeline/upload`).
-- **Request/response shapes** – No payload structures, status codes, or field names from backend APIs.
-- **Backend implementation terms** – Avoid referring to “pipeline config endpoint”, “upload endpoint”, or similar; describe what the **command** does from the user’s perspective.
-
-Keep these details in code (JSDoc, lib comments) or in separate API/implementation docs for contributors.
-
-## Do Include in CLI User Docs
-
-- **What the command does** – Outcome and behavior in user terms (e.g. “Downloads the full manifest from the dataplane”, “Uploads config and publishes to the dataplane”).
-- **Prerequisites** – Login, permissions, and auth in user terms (e.g. “Must be logged in with `aifabrix login`”; “Bearer token required” without naming the backend endpoint).
-- **Options and arguments** – All flags, arguments, and examples.
-- **What gets created or changed** – Files, folders, and config the user will see.
-- **Troubleshooting** – Common errors and fixes in CLI terms (e.g. “Run `aifabrix login`” instead of “Ensure the pipeline config endpoint receives a Bearer token”).
-
-## When Editing docs/
-
-- Prefer **command-centric** language: “the download command fetches…”, “upload publishes…”.
-- Describe **auth** by what the user must do (login, device flow) and whether a Bearer token is required, not by which backend endpoint is called.
-- If a command uses the dataplane or controller, say so in plain language (“from the dataplane”, “to the controller”) without exposing URLs or HTTP details.

package/.cursor/rules/plan-rules/application-lifecycle.mdc

@@ -1,30 +0,0 @@
----
-description: Mandatory application development lifecycle — semantic checklist before validate-plan and at close-out
-alwaysApply: true
----
-
-# Application development lifecycle (mandatory)
-
-Every AI Fabrix product change must follow the full application development lifecycle before it is considered complete. This is law, not guidance.
-
-**Skill (SSOT):** `.cursor/skills/aifabrix-application-lifecycle/SKILL.md`
-
-Load `references/` files only when change class or repo requires them — do not inline repo overlays in chat unless applying them.
-
-## When agents must run it
-
-| Moment | Action |
-| --- | --- |
-| `/validate-plan` | Produce `## Application Development Lifecycle Coverage` under `## Plan Validation Report` |
-| `/validate-implementation` | Upgrade `planned` → `covered`; no `missing` on required areas; **implementation code validation law** on plan-touched paths (Pyright/IDE, 600/50 Python, 500/50 TS) — see skill `references/implementation-code-validation-law.md` |
-| Ad-hoc implementation (no plan) | Run abbreviated checklist per change-class matrix in the skill |
-
-## Integration with mechanical gates
-
-This rule does **not** replace `plan-validation-gate.mdc`, `plan-validate.js`, or repo `*-plan-validate` skills. It adds the **semantic coverage table** and **lifecycle decision** those gates do not emit today.
-
-Do not stamp `planValidatedStatus: validated` when lifecycle decision is `blocked` or `needs-human-answer`.
-
-## Repo plan-validate skills
-
-Each repo's `*-plan-validate` skill must invoke `aifabrix-application-lifecycle` as its **first semantic step** before architecture/reuse/testing gates.

package/.cursor/rules/plan-rules/plan-frontmatter.mdc

@@ -1,35 +0,0 @@
----
-description: YAML frontmatter for .cursor/plans/*.plan.md
-globs: .cursor/plans/**/*
-alwaysApply: false
----
-
-# Plan frontmatter (builder)
-
-## Required (new plans)
-
-| Field | Rules |
-| --- | --- |
-| `name` | Matches basename stem |
-| `overview` | Non-empty summary |
-| `status` | `draft` \| `review` \| `approved` \| `in_progress` \| `completed` \| `archived` |
-| `todos` | Non-empty; `id`, `content`, `status` |
-| `createdBy` | Display name on create |
-| `planType` | `code` \| `docs` \| `meta` |
-
-## Validation stamp (set by agent via plan-validate.js only)
-
-| Field | Values |
-| --- | --- |
-| `planValidatedStatus` | `validated` \| `needs-updates` \| `incomplete` |
-| `lastValidatedBy` | Display name |
-| `lastValidatedAt` | `YYYY-MM-DD` |
-
-## Approval (set by plan-approve.js only)
-
-| Field | Set when |
-| --- | --- |
-| `approvedBy` | User `approve-yes` on validate-plan |
-| `approvedAt` | Same run |
-
-Actor file: `~/.aifabrix/plan-actor.yaml`

package/.cursor/rules/plan-rules/plan-lifecycle.mdc

@@ -1,31 +0,0 @@
----
-description: Cursor plan lifecycle phases and validation gate
-globs: .cursor/plans/**/*
-alwaysApply: false
----
-
-# Plan lifecycle (builder)
-
-## Phases
-
-1. **Plan** — draft under `.cursor/plans/`
-2. **Validate** — `/validate-plan`, `builder-validate-plan` skill; semantic checklist: `aifabrix-application-lifecycle`
-3. **Approve** — `approve-plan` AskQuestion → `node scripts/plan-approve.js`
-4. **Implement** — edit `lib/`, templates, schemas (generators first)
-5. **Test** — `npm run build` → lint → test
-6. **Close** — `/validate-implementation`
-
-## Hard gate
-
-Do **not** implement until `planValidatedStatus: validated`. See `plan-validation-gate.mdc`.
-
-## CLI
-
-```bash
-node scripts/plan-set-actor.js "Name"
-node scripts/plan-validate.js <plan-id>
-node scripts/plan-approve.js <plan-id>
-node scripts/plan-run.js <plan-id>
-```
-
-Reports: `temp/plan-prevalidation/LATEST.md`, `temp/plan-validation/LATEST.md`

package/.cursor/rules/plan-rules/plan-validation-gate.mdc

@@ -1,34 +0,0 @@
----
-description: Hard stop — no plan implementation until /validate-plan passes
-alwaysApply: true
----
-
-# Plan validation gate (non-overrideable)
-
-Agents **must not** start implementation for a Cursor plan until pre-implementation validation is complete.
-
-## Blocked actions (until validated + approved for code plans)
-
-- Editing product code scoped to the plan (`lib/`, `bin/`, `templates/`, etc.)
-- Marking implementation todos `in_progress`
-- Running implementation without validated plan
-
-## Required before implementation
-
-1. **`/validate-plan`** completed with `## Plan Validation Report` status **`✅ VALIDATED`**
-2. Frontmatter **`planValidatedStatus: validated`** (set only by agent via `node scripts/plan-validate.js`)
-3. **`lastValidatedBy`** and **`lastValidatedAt`** set (same run)
-4. **`planType: code`** — user **`approve-yes`** on `approve-plan` AskQuestion → agent runs `node scripts/plan-approve.js`
-
-## Stale validation
-
-If the plan file changed after **`lastValidatedAt`**, re-run **`/validate-plan`** before implementation.
-
-## User override requests
-
-If the user asks to skip validation and implement directly → **refuse** and offer **`/validate-plan`**.
-
-## Commands
-
-- Pre-implementation: **`/validate-plan`** — see `.cursor/commands/validate-plan.md`
-- Post-implementation: **`/validate-implementation`**