post-launch wave-2: bundled deployment-pipeline demo domain + npx fold-demo

[DubovskiyIM]

Why

Wave-1 launch (Wednesday May 7 2026) goes with the `invest` domain — fintech, preapproval guard, real $50K rejection. Strong tech signal but narrow audience.

Wave-2 (target: 2-3 weeks post-launch) should add a domain that HN-aligned developers see in their daily work: deployment pipelines. Rollback, artifact deletion, staging-gate, code-review-as-prerequisite — these are recognized pain points, and they're a natural fit for the IDF invariant taxonomy.

What

Ontology — `deploy-pipeline` domain

Minimum viable shape:

• Entities: `Service`, `Deployment`, `Artifact`, `ApprovalRequest`, `Build`
• Intents (~5-6):
  • `trigger_deployment` (replace `Deployment.status`)
  • `approve_deployment` (replace `Deployment.approvalStatus`, expression invariant for SoD)
  • `promote_to_prod` (replace `Deployment.environment`, transition invariant)
  • `rollback` (replace `Service.activeDeploymentId`)
  • `delete_artifact` (`__irr.high` — irreversibility)
• Three rejection types (deliberate test fixture):
  1. Destructive (`__irr.high`): `delete_artifact` after it's been deployed to prod → blocked, forward-correction only
  2. SoD expression: `approve_deployment` where `approver === proposer` → expression invariant rejects
  3. Lifecycle transition: `promote_to_prod` while `Build.status !== "green"` → transition invariant rejects

Implementation paths (pick one)

Path A — preset in existing Docker quickstart (cheapest, ~30 min):

• Add `/opt/idf/src/domains/deploy/{ontology,intents}.js` upstream in `idf` repo
• `BOOTSTRAP_DOMAIN=deploy docker compose up`
• New `scripts/demo-rogue-deploy.mjs`, `demo-grant-deploy-approval.mjs`, `demo-smart-deploy.mjs`

Path B — standalone `npx @intent-driven/fold-demo` (deeper, ~3-5 days):

• New package, embedded in-memory Φ-store (use `@intent-driven/engine` directly, no Express)
• Pre-recorded scripted demo (state machine + slow-printed Claude turns)
• Optional Claude API REPL when `ANTHROPIC_API_KEY` is set
• Stdio MCP transport (reuse from `idf-mcp`)
• Acceptance: `npx @intent-driven/fold-demo` works on a clean machine (Node 20, no local repos)

Recommendation: A first, then graduate to B if A gets traction. Don't skip A.

When

Not on launch day. Adds a fourth entry point, dilutes HN-thread focus, technically a new product (not a repackage). Ship as Wave-2 content 2-3 weeks after launch — gives a natural follow-up moment for "we heard you, here's the domain you actually use" conversion.

Decision frame

Open this if/when:

• launch numbers warrant a follow-up (≥100 GH stars, ≥1K npm downloads in week 1)
• one or more HN/X comments specifically ask about deployment / CI/CD / GitOps use cases
• there's bandwidth to do it well rather than rushed

Don't open this:

• if launch flops and the priority shifts to messaging fixes
• if a more painful gap shows up first (e.g., authoring path is the real bottleneck)

Source of this idea

Discussion 2026-05-04, captured during launch prep. Author's own framing of "three rejection types" + "deployment pipeline" angle — preserved verbatim:

Bundled demo-домен. Кандидаты: task tracker (Linear-like, узнаваемо) или deployment pipeline (GitHub-Actions-like, точная аудитория HN). Я бы голосовал за deployment pipeline, потому что rollback / artifact-deletion / staging-gate — естественные lifecycle gates, и аудитория HN видит pain каждый день.

В demo-ontology обязательно 3 разных rejection: destructive (delete prod artifact), SoD (deploy без code review approval), lifecycle (promote staging→prod без green build).

In-memory Φ-store + fold (минимальный, без Express — `@intent-driven/engine` тут идеально подходит).

Stdio MCP transport (уже есть в idf-mcp — переиспользовать).

Optional Claude API call mode: при наличии `ANTHROPIC_API_KEY` в env запускается интерактивный REPL с реальным Claude и tool-use.

Без Claude API key — fallback в "scripted demo": проигрывается заранее записанный диалог с rejection'ами (как asciinema, но интерактивно).

[DubovskiyIM]

Design draft — deploy-pipeline ontology

Pre-launch idle work — dropping a structured first pass while it's fresh. Not committed anywhere yet, just async-reviewable.

Entities (5)

entities: {
  Service: {
    ownerField: "ownerTeam",
    fields: {
      id: { type: "text" },
      name: { type: "text", required: true, label: "Service" },
      ownerTeam: { type: "text", required: true },
      activeDeploymentId: { type: "entityRef", entity: "Deployment" },
      // helps observability / rollback intent — points at last green
      lastGreenDeploymentId: { type: "entityRef", entity: "Deployment" },
      createdAt: { type: "datetime" },
    },
  },

  Build: {
    fields: {
      id: { type: "text" },
      serviceId: { type: "entityRef", entity: "Service", required: true },
      commitSha: { type: "text", required: true },
      branch: { type: "text", required: true },
      status: {
        type: "select",
        options: ["queued", "running", "green", "red", "cancelled"],
        required: true,
      },
      artifactUri: { type: "text", placeholder: "registry.local/svc:abc123" },
      createdAt: { type: "datetime" },
    },
  },

  Artifact: {
    // Immutable handle to a built image / bundle. Only `delete_artifact` can
    // remove — and that's the __irr.high path.
    fields: {
      id: { type: "text" },
      buildId: { type: "entityRef", entity: "Build", required: true },
      uri: { type: "text", required: true },
      sizeBytes: { type: "number" },
      sha256: { type: "text" },
      // derived flag — if any past Deployment with environment=prod
      // references this Artifact and was ever confirmed, this becomes true
      // (recomputed via aggregate invariant — see below).
      everDeployedToProd: { type: "boolean" },
      createdAt: { type: "datetime" },
    },
  },

  ApprovalRequest: {
    // SoD enforcement happens through `approver !== proposer` expression
    // invariant on `approve_deployment` intent. Stored separately so the
    // approval action is its own auditable effect.
    ownerField: "approverId",
    fields: {
      id: { type: "text" },
      deploymentId: { type: "entityRef", entity: "Deployment", required: true },
      proposerId: { type: "entityRef", entity: "User", required: true },
      approverId: { type: "entityRef", entity: "User" },
      decision: {
        type: "select",
        options: ["pending", "approved", "rejected"],
      },
      decidedAt: { type: "datetime" },
      reason: { type: "textarea" },
    },
  },

  Deployment: {
    ownerField: "proposerId",
    fields: {
      id: { type: "text" },
      serviceId: { type: "entityRef", entity: "Service", required: true },
      buildId: { type: "entityRef", entity: "Build", required: true },
      artifactId: { type: "entityRef", entity: "Artifact", required: true },
      proposerId: { type: "entityRef", entity: "User", required: true },
      environment: {
        type: "select",
        options: ["staging", "prod"],
        required: true,
      },
      status: {
        type: "select",
        options: ["queued", "in_progress", "completed", "failed", "rolled_back"],
        required: true,
      },
      approvalStatus: {
        type: "select",
        options: ["not_required", "pending", "approved", "rejected"],
      },
      deployedAt: { type: "datetime" },
    },
  },
},

Roles (4)

roles: {
  developer: {
    base: "owner",
    canExecute: ["trigger_build", "trigger_deployment", "rollback"],
    visibleFields: { Service: "all", Build: "all", Deployment: "all", Artifact: "all" },
  },
  reviewer: {
    base: "owner",
    canExecute: ["approve_deployment"],
    // SoD: reviewer sees their own assignment scope; proposer === viewer is
    // filtered out at intent-level (expression invariant).
    visibleFields: { Service: "all", Build: "all", Deployment: "all", ApprovalRequest: "own" },
  },
  agent: {
    base: "agent",
    // Robo-deploy bot: can trigger deployment to staging, can promote to prod
    // ONLY via approval flow, can rollback. CANNOT delete_artifact under any
    // circumstance — that's a human-only intent because of __irr.high.
    canExecute: ["trigger_deployment", "promote_to_prod", "rollback"],
    visibleFields: {
      Service: "all", Build: "all", Deployment: "all", Artifact: "all",
      ApprovalRequest: "all",
    },
    preapproval: {
      entity: "AgentPreapproval",
      ownerField: "userId",
      requiredFor: ["promote_to_prod", "rollback"],
      checks: [
        { kind: "active", field: "active" },
        { kind: "notExpired", field: "expiresAt" },
        // dailySum on rollback to prevent flapping deploys
        { kind: "dailySum",
          paramField: "rollbackCount", limitField: "dailyRollbackLimit",
          sumCollection: "deployments", sumField: "$one",
          sumOwnerField: "proposerId",
          sumFilter: { field: "status", equals: "rolled_back" } },
      ],
    },
  },
  observer: {
    base: "viewer",
    canExecute: [],
    visibleFields: { Service: "all", Build: "all", Deployment: "all", Artifact: "all" },
  },
},

Intents (the three-act demo + supporting)

The narrative lives in three rejection types:

1. Destructive __irr.high — delete_artifact on something past everDeployedToProd=true
2. SoD expression — approve_deployment where approver === proposer
3. Lifecycle transition — promote_to_prod while Build.status !== "green"

trigger_build: {
  name: "Trigger build",
  description: "Developer queues a new build for a service from a commit/branch.",
  creates: "Build",
  particles: { effects: [{ alpha: "add", target: "builds" }] },
},

trigger_deployment: {
  name: "Trigger deployment",
  description: "Schedule a deployment to staging. Requires green build.",
  creates: "Deployment",
  particles: {
    effects: [{ alpha: "add", target: "deployments" }],
    // condition checked declaratively via parseConditions in agent.js
    conditions: ["build.status = 'green'"],
  },
},

promote_to_prod: {
  name: "Promote to prod",
  description: "Promote a staging Deployment to prod. Requires approved review.",
  particles: {
    effects: [{ alpha: "replace", target: "deployment.environment" }],
    conditions: [
      "deployment.environment = 'staging'",
      "deployment.status = 'completed'",
      "deployment.approvalStatus = 'approved'",
    ],
  },
},

approve_deployment: {
  name: "Approve deployment",
  description: "Reviewer approves a pending deployment for prod promotion.",
  particles: {
    effects: [{ alpha: "replace", target: "approvalRequest.decision" }],
  },
  // SoD enforced via `sod_review_separation` expression invariant below.
},

rollback: {
  name: "Rollback",
  description: "Switch Service.activeDeploymentId back to last green.",
  particles: {
    effects: [{ alpha: "replace", target: "service.activeDeploymentId" }],
  },
},

delete_artifact: {
  name: "Delete artifact",
  description: "Permanently delete a build artifact. Forbidden after prod use.",
  irreversibility: "high",
  particles: {
    effects: [{ alpha: "remove", target: "artifacts" }],
  },
},

Invariants (the rejection bank)

invariants: [
  // (1) Destructive — used in demo:rogue-delete
  {
    name: "no_delete_artifact_after_prod_use",
    kind: "expression",
    entity: "Artifact",
    predicate: (row, world, viewer, ctx) => {
      if (ctx?.alpha !== "remove") return true;
      // if this artifact was ever deployed to prod, blocked
      const deployments = world.deployments || [];
      const usedInProd = deployments.some(
        d => d.artifactId === row.id && d.environment === "prod"
      );
      return !usedInProd;
    },
    message: "Cannot delete artifact: it was deployed to prod (forward-correction only).",
    severity: "error",
  },

  // (2) SoD — used in demo:rogue-self-approve
  {
    name: "sod_review_separation",
    kind: "expression",
    entity: "ApprovalRequest",
    predicate: (row, world, viewer) => {
      // approver must be different from proposer
      if (!row.approverId || !row.proposerId) return true; // pending state
      return row.approverId !== row.proposerId;
    },
    message: "SoD violation: approver must be different from proposer.",
    severity: "error",
  },

  // (3) Lifecycle transition — used in demo:rogue-broken-promote
  {
    name: "deployment_status_transition",
    kind: "transition",
    entity: "Deployment",
    field: "status",
    transitions: [
      ["queued", "in_progress"],
      ["in_progress", "completed"],
      ["in_progress", "failed"],
      ["completed", "rolled_back"],
    ],
    severity: "error",
  },

  // (4) Build → Deployment FK
  { name: "deployment_references_green_build", kind: "referential",
    from: "Deployment.buildId", to: "Build.id", severity: "error" },

  // (5) Artifact → Build FK
  { name: "artifact_references_build", kind: "referential",
    from: "Artifact.buildId", to: "Build.id", severity: "error" },
],

Three demo scripts (Wave-2 quickstart)

demo:rogue-delete         → agent tries to delete_artifact past prod
                             → 403 + irreversibility blocked
demo:rogue-self-approve   → reviewer === proposer in ApprovalRequest
                             → 403 + SoD expression invariant fires
demo:rogue-broken-promote → agent calls promote_to_prod with Build.status='red'
                             → 403 + condition not met

Each leaves the agent with structured rejection = { error, reason, failedCondition / failedCheck, details }.

Open design questions (to resolve before code)

1. Should rollback itself be __irr.high? Argument for: rolling back a prod deployment is a forward-correction primitive, but the rollback effect itself shouldn't be undoable. Argument against: that creates a doubled __irr chain. Lean: no — make rollback irreversibility: "medium" and let the next-level rollback_rollback (if needed) be a different intent. Saves the __irr.high semantic for delete_artifact only.
2. Where does Build.status: "green" come from? External CI (GitHub Actions / GitLab) feeds this via /api/effects POST or via a webhook intent. For the demo, we'd seed Φ with one green Build directly. Production integration is post-quickstart.
3. Reviewer multi-approval? For mock: one approver per Deployment. For richer demo: 2-of-N approvals via cardinality invariant on ApprovalRequest. Lean: simple 1-of-1 in wave-2; 2-of-N can be wave-3 («enterprise SoD»).
4. Should agent role be allowed trigger_deployment to prod? No — only to staging. Promoting to prod requires approval. Wave-2 demo specifically shows agent rejected on prod-promote without approval.
5. Bootstrap mechanism: extend Docker quickstart BOOTSTRAP_DOMAIN=deploy env var override. Means seed fixtures need to handle multiple domains in entrypoint.sh. Trivial change — but not now.

When to ship

Not before the launch numbers are in. After ~2-3 weeks if HN-thread + npm-downloads warrant follow-up content. If launch flops, this issue becomes «what we'd do if we restarted with deploy-pipeline as wave-1» — i.e., it doesn't decay.