@aifabrix/builder 2.58.0 → 2.60.0

package/templates/agent-kit/skills/aifabrix-connected-system/SKILL.md

@@ -10,7 +10,14 @@ description: >
 # aifabrix-connected-system
 
 Phases: `plan` | `validate` | `build` | `publish`.
-Resolve phase: explicit argument → plan/package state → safe next → ask once.
+
+**No phase argument means report only.** Inspect, print the combined status matrix,
+recommend one next phase, and stop. Do not upload, deploy, advance a plan task, create
+proof assets, run cases, or mutate anything until the user names a phase or picks a route:
+[status.md](../shared/status.md).
+
+Resolve phase: explicit argument → ask. Package state informs the recommendation, never
+the action.
 
 Stop at the phase gate. Do not run the next phase without `next-yes`
 ([interaction.md](../aifabrix-plan/references/interaction.md)).
@@ -22,6 +29,28 @@ Stop at the phase gate. Do not run the next phase without `next-yes`
 | build | READY | BUILT |
 | publish | package exists and local validate passes | PASS or PASS_WITH_SKIPS |
 
+READY and BUILT are **package** gates: they describe files on disk, not a working or
+published system. Report them qualified, beside the Delivery row
+([status.md](../shared/status.md)).
+
+## Publish and certification verdicts
+
+Compute the verdict with
+[scripts/delivery-verdict.js](scripts/delivery-verdict.js) from what you observed; do not
+choose it by narrative.
+
+| Observation | Verdict |
+| --- | --- |
+| Online state Draft | publish incomplete; prove BLOCKED; Delivery NEEDS_FIXES |
+| Operations FAILED | NEEDS_FIXES |
+| Known ABAC, persistence, capability, or live-evidence failure | NEEDS_FIXES while open |
+| Bronze or TECHNICALLY_READY alone | not PASS |
+| Online Published **and** acceptable Operations, Trust, Governance and live evidence | PASS |
+| The above with only explicitly allowed skips | PASS_WITH_SKIPS |
+
+`PASS_WITH_SKIPS` covers skips the user allowed by name. It may never cover a known
+failure, an unrun gate, or a gate whose result you did not see.
+
 Read current CLI help before composing commands. You own orchestration, not CLI implementation.
 Host runtimes (local vs SSH): [hosts.md](../shared/hosts.md).
 CLI login from chat: [login.md](../shared/login.md).
@@ -38,6 +67,7 @@ System key: argument → active plan → sole `integration/` folder → ask once
 
 ## References
 
+- [status.md](../shared/status.md) — read-only default, route options, status matrix
 - [delivery-gates.md](references/delivery-gates.md) — BID/wizard/repair, upload vs deploy, tests, identity, protection
 - [contract-checklist.md](references/contract-checklist.md) — exposed, FK, viewpoints, RBAC/ABAC
 - [production-safety.md](references/production-safety.md) — designated subject, credential-deferred E2E
@@ -52,6 +82,8 @@ System key: argument → active plan → sole `integration/` folder → ask once
 - Upload without deploy is not published and not PASS
 - No system-level sync of views
 - No publish continuation after an unresolved hard failure
+- A known failure stays open until that same concern is rerun and passes
+- No bare READY/BUILT/PASS headline when Delivery is NEEDS_FIXES or BLOCKED
 
 ## Trigger examples
 

package/templates/agent-kit/skills/aifabrix-connected-system/scripts/delivery-verdict.js

@@ -0,0 +1,176 @@
+/**
+ * Delivery verdict for a customer Connected System and Role Assistant.
+ *
+ * The agent records what it observed; this decides the verdict. Keeping the decision here
+ * rather than in skill prose means a passing package cannot be narrated into a passing
+ * delivery: precedence is computed, not chosen.
+ *
+ * Gates are reported separately on purpose. A package can be BUILT while the delivery
+ * needs fixes and prove is blocked, and all three are true at once.
+ *
+ * @fileoverview Deterministic status matrix and overall verdict for customer delivery skills
+ */
+
+'use strict';
+
+/** Worst-first. A later gate never improves an earlier one. */
+const RANK = ['BLOCKED', 'NEEDS_FIXES', 'PASS_WITH_SKIPS', 'PASS'];
+const UNKNOWN = 'UNKNOWN';
+
+/**
+ * @param {string} a First verdict
+ * @param {string} b Second verdict
+ * @returns {string} The worse of the two
+ */
+function worse(a, b) {
+  const left = RANK.indexOf(a);
+  const right = RANK.indexOf(b);
+  if (left < 0) return b;
+  if (right < 0) return a;
+  return left <= right ? a : b;
+}
+
+/**
+ * Trim and uppercase an observed field. Missing values become an empty string.
+ * @param {*} value Observed field
+ * @returns {string} Normalized token
+ */
+function norm(value) {
+  return String(value === undefined || value === null ? '' : value).trim().toUpperCase();
+}
+
+/**
+ * Published is the only online state that permits publish completion or live prove.
+ * @param {object} signals Observed signals
+ * @returns {{ state: string, published: boolean, known: boolean }} Online state
+ */
+function onlineState(signals) {
+  const state = norm(signals.onlineState) || UNKNOWN;
+  return {
+    state,
+    published: state === 'PUBLISHED',
+    known: state === 'PUBLISHED' || state === 'DRAFT'
+  };
+}
+
+/**
+ * Builder's pillar verdicts are VERIFIED, FAILED, NOT_VERIFIED and NOT_APPLICABLE
+ * (`lib/lifecycle/product-model.js`). NOT_VERIFIED is not a pass — it is the state a pillar
+ * sits in until it has actually been proved, and treating it as neutral is how an
+ * unverified system gets reported as delivered. A gate that was never run is UNKNOWN.
+ * @param {object} gate Observed gate result
+ * @returns {string} Normalized verdict
+ */
+function gateVerdict(gate) {
+  if (!gate) return UNKNOWN;
+  const verdict = norm(gate.verdict);
+  if (!verdict || verdict === 'NOT_RUN' || verdict === 'SKIPPED') return UNKNOWN;
+  if (verdict === 'VERIFIED' || verdict === 'PASSED' || verdict === 'PASS') return 'PASS';
+  if (verdict === 'NOT_APPLICABLE') return 'PASS';
+  if (verdict === 'FAILED' || verdict === 'FAIL' || verdict === 'NOT_VERIFIED') return 'NEEDS_FIXES';
+  return 'NEEDS_FIXES';
+}
+
+/**
+ * Failures stay active until the same concern is rerun and passes, so a later structural
+ * success cannot clear an earlier runtime, governance, persistence, or E2E failure.
+ * @param {Array} knownFailures Recorded failures
+ * @returns {Array} Failures still open
+ */
+function openFailures(knownFailures) {
+  const rows = Array.isArray(knownFailures) ? knownFailures : [];
+  return rows.filter(row => row && row.resolved !== true && norm(row.resolved) !== 'TRUE');
+}
+
+/**
+ * One status-matrix cell: verdict plus an optional percent.
+ * @param {object} gate Observed gate result
+ * @returns {string} Display text
+ */
+function describeScore(gate) {
+  if (!gate) return UNKNOWN;
+  const verdict = norm(gate.verdict) || norm(gate.category) || UNKNOWN;
+  const percent = gate.percent === undefined || gate.percent === null ? '' : ` ${gate.percent}%`;
+  return `${verdict}${percent}`;
+}
+
+/**
+ * Overall delivery verdict. PASS needs a published system and acceptable Operations,
+ * Trust, Governance and live-evidence results; an unrun gate is not a pass. BLOCKED is
+ * reserved for a delivery that cannot be assessed or was explicitly stopped — a draft
+ * system is fixable work, so it reports NEEDS_FIXES.
+ * @param {object} signals Observed signals
+ * @returns {string} BLOCKED | NEEDS_FIXES | PASS_WITH_SKIPS | PASS
+ */
+function overallVerdict(signals) {
+  const online = onlineState(signals);
+  if (!online.known || signals.blocked === true) return 'BLOCKED';
+  let verdict = online.published ? 'PASS' : 'NEEDS_FIXES';
+  for (const gate of [signals.operations, signals.trust, signals.governance, signals.liveEvidence]) {
+    const result = gateVerdict(gate);
+    verdict = worse(verdict, result === UNKNOWN ? 'NEEDS_FIXES' : result);
+  }
+  if (openFailures(signals.knownFailures).length > 0) verdict = worse(verdict, 'NEEDS_FIXES');
+  const skips = Array.isArray(signals.allowedSkips) ? signals.allowedSkips : [];
+  if (verdict === 'PASS' && skips.length > 0) return 'PASS_WITH_SKIPS';
+  return verdict;
+}
+
+/**
+ * Prove readiness is a business-case gate. Package validation, pipeline checks, a Bronze
+ * certification or TECHNICALLY_READY never establish it on their own.
+ * @param {object} signals Observed signals
+ * @returns {string} READY | BLOCKED
+ */
+function proveReadiness(signals) {
+  const overall = overallVerdict(signals);
+  if (overall !== 'PASS' && overall !== 'PASS_WITH_SKIPS') return 'BLOCKED';
+  const ra = signals.roleAssistant || {};
+  // `role-assistant test --json` gives the verdict. Availability is an operator action with
+  // no CLI surface, so it must be confirmed explicitly; unconfirmed is not available.
+  if (gateVerdict(ra) !== 'PASS' || norm(ra.availability) !== 'AVAILABLE') return 'BLOCKED';
+  const cases = signals.cases || {};
+  if (cases.happy !== true || cases.safeStop !== true) return 'BLOCKED';
+  if (signals.authorityConfirmed !== true) return 'BLOCKED';
+  return 'READY';
+}
+
+/**
+ * Every row the skills must report, in a fixed order.
+ * @param {object} signals Observed signals
+ * @returns {Array<{ gate: string, value: string }>} Status matrix rows
+ */
+function statusMatrix(signals) {
+  const ra = signals.roleAssistant || {};
+  const availability = `${norm(ra.availability) || UNKNOWN}/${norm(ra.verdict) || UNKNOWN}`;
+  return [
+    { gate: 'Package', value: norm(signals.packageGate) || UNKNOWN },
+    { gate: 'Online', value: onlineState(signals).state },
+    { gate: 'AI Readiness', value: describeScore(signals.aiReadiness) },
+    { gate: 'Operations', value: describeScore(signals.operations) },
+    { gate: 'Trust', value: describeScore(signals.trust) },
+    { gate: 'Governance', value: describeScore(signals.governance) },
+    { gate: 'Role Assistant', value: availability },
+    { gate: 'Prove readiness', value: proveReadiness(signals) },
+    { gate: 'Delivery', value: overallVerdict(signals) }
+  ];
+}
+
+/**
+ * A headline may not claim success the overall verdict does not support.
+ * @param {object} signals Observed signals
+ * @returns {boolean} True when a bare READY, BUILT or PASS headline is forbidden
+ */
+function forbidsSuccessHeadline(signals) {
+  const overall = overallVerdict(signals);
+  return overall === 'BLOCKED' || overall === 'NEEDS_FIXES';
+}
+
+module.exports = {
+  worse,
+  statusMatrix,
+  overallVerdict,
+  proveReadiness,
+  openFailures,
+  forbidsSuccessHeadline
+};

package/templates/agent-kit/skills/aifabrix-plan/SKILL.md

@@ -12,6 +12,9 @@ description: >
 Input: business specification and optional `systemKey`.
 Output: one delivery plan from [plan-template.md](references/plan-template.md).
 
+Named with no specification, report what exists and ask; do not start writing a plan from
+an inferred spec ([status.md](../shared/status.md)).
+
 Score completeness with [challenge-checklist.md](references/challenge-checklist.md).
 Next-step interaction: [interaction.md](references/interaction.md).
 Host runtimes (local vs SSH): [hosts.md](../shared/hosts.md).

package/templates/agent-kit/skills/aifabrix-plan/references/interaction.md

@@ -24,11 +24,18 @@ Archive is a distinct user decision (`archive-yes` / `archive-no`). Never archiv
 - NEEDS_DECISIONS: AskQuestion challenge rows. No `cust-next`.
 - BLOCKED / FAIL / NEEDS_FIXES / ABORTED: do not offer the next phase as if success.
 
+A phase gate is per-gate, not overall. Offer the next phase only when the **Delivery** row
+supports it; a passing package gate beside `Delivery: NEEDS_FIXES` is not success and the
+offer must name what is still open.
+
 ## Phase detection (connected-system and prove)
 
 1. Explicit phase from the user
-2. Active plan and package state
-3. Safe next eligible phase
-4. Ask once if ambiguous
+2. Ask, offering the routes in [status.md](../../shared/status.md)
+
+There is no third step. Package and plan state decide what you *recommend*, never what you
+run: a bare invocation reports status and stops ([status.md](../../shared/status.md)).
+Inferring "the safe next eligible phase" is what makes a skill start working before the
+user has said what they want.
 
 Never silently run the following phase after success.

package/templates/agent-kit/skills/aifabrix-prove/SKILL.md

@@ -12,8 +12,30 @@ description: >
 Phases: `validate` | `build` | `prove`.
 Loop: validate ↔ build ↔ prove ↔ learn.
 
+**No phase argument means run prove-readiness validation only.** Report the combined status
+matrix and the readiness verdict, recommend one next phase, and stop. Do not build proof
+assets, run cases, publish, or promote: [status.md](../shared/status.md).
+
 `READY` means prove-ready, not permission to stop authoring. Build may run without READY.
 
+## Prove readiness
+
+READY requires **all** of:
+
+- Connected System PASS, or PASS_WITH_SKIPS whose skips the user allowed by name
+- online state Published
+- Operations not failed
+- relevant governance scenarios passed
+- Role Assistant available and verified
+- happy and safe-stop cases present for the scenarios in scope
+- authority, test subjects, and required business inputs confirmed
+
+Anything short of all of them is BLOCKED, reported with the row that blocks it.
+[delivery-verdict.js](../aifabrix-connected-system/scripts/delivery-verdict.js) computes it.
+
+Package validation, pipeline checks, Bronze certification and TECHNICALLY_READY are **not**
+business-case readiness. None of them, alone or together, makes prove READY.
+
 Every phase **must** update [learning-template.md](references/learning-template.md).
 Evidence rules: [evidence-lifecycle.md](references/evidence-lifecycle.md).
 Demo shape: [demo-template.md](references/demo-template.md).

package/templates/agent-kit/skills/aifabrix-role-assistant/SKILL.md

@@ -12,6 +12,8 @@ See [package-boundary.md](references/package-boundary.md) and nested `role-assis
 Host runtimes (local vs SSH): [hosts.md](../shared/hosts.md).
 CLI login from chat: [login.md](../shared/login.md).
 
+Named with no task, report status and stop: [status.md](../shared/status.md).
+
 ## Preconditions
 
 ```bash
@@ -22,6 +24,25 @@ aifabrix role list --page-size 1000
 Catalog Business Role and an active user binding are prerequisites.
 Connected Systems this assistant needs must be dataplane **published** (deploy, not upload-only).
 
+## Readiness gate
+
+Report the assistant as available and verified only when every row holds. Any missing row
+means NOT_VERIFIED, named by row — never a blanket claim.
+
+| Row | Established by |
+| --- | --- |
+| Active catalog role | `aifabrix role list --page-size 1000` |
+| Required Connected Systems published **and** certified | `show --online` plus their Delivery verdict |
+| Subscribed capabilities available | capability check against those systems |
+| OpenAPI published | `role-assistant test --json` → `openApiPublished` |
+| Lifecycle verified | `role-assistant test --json` → `verdict` is `VERIFIED` |
+| Worker available | operator "Make available"; **no CLI surface** — confirm explicitly or report UNKNOWN |
+| Happy and safe-stop cases discoverable | cases present for the scenarios in scope |
+
+A published Connected System that is not certified does not satisfy row two. `verdict`
+`NOT_VERIFIED` is not a pass, and a `certification.level` such as `BRONZE` never
+substitutes for it.
+
 ## Workflow
 
 1. `aifabrix download <catalogRoleOrRaKey>` before editing an existing assistant.

package/templates/agent-kit/skills/shared/feedback.md

@@ -0,0 +1,31 @@
+# Feedback — where an observation goes
+
+`aifabrix agent-kit update` rewrites `.agents/skills/**`, `AGENTKIT.md`, and the
+managed sections of `AGENTS.md` and `CLAUDE.md` from the installed kit. Editing
+them blocks the next update as a conflict, and `--force` discards the edit with
+no diff to review. Improve the kit by filing a finding, not by editing a skill.
+
+| Observation | Where it goes |
+| --- | --- |
+| Generic CLI, skill, or platform gap | `BUILDER_IMPROVEMENT_FINDINGS.md` |
+| Manual EDS edit | `integration/<systemKey>/INTEGRATION_CHANGELOG.md` |
+| Vendor limits, tenant ids, PII stance | `integration/<systemKey>/README.md` |
+| Delivery learning for a role | `role-assistant/ra-<roleKey>/learning/learning.md` |
+
+## Writing a finding
+
+Newest first, under a `## YYYY-MM-DD — one line naming the gap` heading:
+
+- **Command** — the exact command, customer values replaced by placeholders.
+- **Observed** — what happened, with the error text and the verdict.
+- **Expected** — what should have happened, and why that is reasonable.
+- **Scope** — whether it reproduces outside this workspace, and what is still
+  unproven. Say so plainly when the root cause is not established.
+
+A finding is read outside this workspace, so leave out correlation ids, audit
+refs, internal URLs, tenant or record identifiers, hostnames, and customer
+names. Customer specifics belong in the package README or the role's
+`learning.md` instead.
+
+Never weaken a gate, assertion, or test to make a finding go away. A failing
+gate with a filed finding is a better outcome than a green run that hides one.

package/templates/agent-kit/skills/shared/hosts.md

@@ -6,6 +6,11 @@ Install and sign-in steps are in `AGENTKIT.md`. This file is how to **run** each
 
 Do not start Claude or Codex in your home directory. `cd` into this git workspace first.
 
+For first-time terminal onboarding, run `aifabrix agent-kit setup <controllerUrl>`.
+It creates a local workspace under AI Fabrix work and starts Codex; use `--code claude`
+to select Claude. GitHub is optional through `--repo owner/name`. Setup preserves
+permission settings; the standalone start defaults below remain separate.
+
 ## Auto-approve
 
 `aifabrix agent-kit install` can write gitignored host configs so Claude Code and Codex do not prompt for every tool:
@@ -13,7 +18,17 @@ Do not start Claude or Codex in your home directory. `cd` into this git workspac
 - Claude Code: `.claude/settings.local.json` (`permissions.defaultMode` = `bypassPermissions`, `allow` = `Bash(aifabrix *)` and `Read(~/**)`)
 - Codex: `.codex/config.toml` (`approval_policy = "never"`, `sandbox_mode = "workspace-write"`)
 
-Those files stay in **this workspace**. Claude may **read** files under the developer home (`Read(~/**)`) and run the delivery CLI (`Bash(aifabrix *)`). They do not add sibling folders as extra workspaces, do not grant Write outside this repo, and do not allow every shell command. `agent-kit start claude|codex` writes only the selected host's file by default; `--skip-approve-all` opts out. Install/update retain their explicit approval prompts and flags. `--force` overwrites existing local files. Builder never writes `~/.claude` or `~/.codex`.
+Those files stay in **this workspace**; Builder never writes `~/.claude` or `~/.codex`, and neither file adds a sibling folder as an extra workspace.
+
+Understand what you are accepting for Claude Code. `bypassPermissions` stops the
+prompt for **every** tool call in this workspace, not only the two `allow`
+entries, which grant nothing extra while that mode is set. That includes
+`aifabrix` subcommands which change remote state, such as `deploy`, `upload`,
+`identity sync` and `protection upload`. Codex is narrower: `approval_policy`
+removes the prompt, while `sandbox_mode = "workspace-write"` still confines
+writes to this workspace.
+
+Use `--skip-approve-all` when you want the prompts, on a shared or production-connected installation. `agent-kit start claude|codex` writes only the selected host's file by default. Install/update retain their explicit approval prompts and flags. `--force` overwrites existing local files.
 
 ## Cursor
 
@@ -23,13 +38,17 @@ Those files stay in **this workspace**. Claude may **read** files under the deve
 
 ## Claude Code
 
-**Local or SSH — tmux.** Closing the terminal must not kill Claude. Agent Kit starts Claude **inside tmux**, with Remote Control and workspace auto-approval enabled by default. Remote Control is the **same** session on this PC, [claude.ai/code](https://claude.ai/code), and the Claude mobile app (**Code**). Do not use `claude --cloud` for this — that starts a different machine that clones GitHub. Claude `--tmux` is only for `--worktree` sessions, not this wrapper.
+On a managed host, `af onboarding --coding claude` starts or reuses a detached
+Claude tmux session and prints how to attach. Its Remote Control session is
+available from the same Claude account when supported.
+
+**Optional terminal session — tmux.** When you choose a terminal workflow, Agent Kit starts Claude **inside tmux**, with Remote Control and workspace auto-approval enabled by default. Remote Control is the **same** session on this PC, [claude.ai/code](https://claude.ai/code), and the Claude mobile app (**Code**). Do not use `claude --cloud` for this — that starts a different machine that clones GitHub. Claude `--tmux` is only for `--worktree` sessions, not this wrapper.
 
 ```bash
 aifabrix agent-kit start claude
 ```
 
-tmux session name is this folder (for example `aifabrix-docs`). Remote Control name is `hostname-user-folder` (for example `builder01-dev03-aifabrix-docs`). `--name` overrides the folder; `--no-remote-control` and `--skip-approve-all` opt out. Several workspaces can run at once. Detach without killing Claude: `Ctrl-b` then `d`. Reattach: `tmux attach -t aifabrix-docs`. A duplicate `start` fails instead of attaching. Then `/aifabrix-plan` (or another `/aifabrix-*` skill). First run in a project asks you to trust the folder; accept only this workspace.
+tmux session name is this folder (for example `acme-workspace`). Remote Control name is `hostname-user-folder` (for example `devhost-alice-acme-workspace`). `--name` overrides the folder; `--no-remote-control` and `--skip-approve-all` opt out. Several workspaces can run at once. Detach without killing Claude: `Ctrl-b` then `d`. Reattach: `tmux attach -t acme-workspace`. A duplicate `start` fails instead of attaching. Then `/aifabrix-plan` (or another `/aifabrix-*` skill). First run in a project asks you to trust the folder; accept only this workspace.
 
 **Phone and PC.** Sign in with the same Claude Pro/Max/Team account (`claude auth login` — not an API key). After Remote Control starts, open **Code** in the Claude mobile app and/or [claude.ai/code](https://claude.ai/code) on the PC. In an already-running session, `/remote-control` or `/mobile`.
 
@@ -37,13 +56,21 @@ Closing the terminal (or SSH) does not stop a tmux session. Stopping tmux or the
 
 ## Codex
 
-**Local or SSH — tmux and Remote Control.** tmux keeps Codex running if you close the terminal or disconnect SSH. Agent Kit also starts Codex's native remote-control daemon and workspace auto-approval by default.
+**Remote SSH project.** Open the workspace printed by `af onboarding` in the
+Codex app. The app's server connection runs separately from tmux, so no tmux
+session is needed for that chat.
+
+**Optional terminal session — tmux and Remote Control.** tmux keeps a separate
+terminal Codex session running if you disconnect SSH. `agent-kit start codex`
+also requests Codex's native Remote Control by default; the npm-installed CLI
+may require `--no-remote-control` because the daemon needs Codex's standalone
+installer.
 
 ```bash
 aifabrix agent-kit start codex
 ```
 
-Default `--name` is the last folder. `--no-remote-control` keeps the launch local; `--skip-approve-all` leaves Codex permissions unchanged. If that session already exists, `start` fails with list/kill guidance. Detach: `Ctrl-b` then `d`. Reattach with `tmux attach -t aifabrix-docs`. Then `$aifabrix-plan` (and the other `$aifabrix-*` skills). Codex reads `AGENTS.md`. Killing tmux does not stop the shared daemon; use `codex remote-control stop` when required.
+Default `--name` is the last folder. `--no-remote-control` skips that daemon; `--skip-approve-all` leaves Codex permissions unchanged. If that session already exists, `start` fails with list/kill guidance. Detach: `Ctrl-b` then `d`. Reattach with `tmux attach -t acme-workspace`. Then `$aifabrix-plan` (and the other `$aifabrix-*` skills). Codex reads `AGENTS.md`. A separate Codex app server used by a desktop SSH chat appears in `agent-kit list` and the interactive `agent-kit kill` menu; stopping it requires confirmation and may disconnect the chat. `codex remote-control stop` only controls a standalone-managed daemon.
 
 **Foreground only (no tmux).**
 
@@ -58,8 +85,9 @@ codex
 | --- | --- |
 | New named session | `tmux new -s <name> -c /path/to/this-workspace` |
 | Detach (leave it running) | `Ctrl-b`, then `d` |
-| List sessions | `aifabrix agent-kit list` |
+| List sessions; choose tmux to attach or Close | `aifabrix agent-kit list` |
 | Attach | `tmux attach -t <name>` |
-| Kill session | `aifabrix agent-kit kill <name>` |
+| Stop tmux by name | `aifabrix agent-kit kill <name>` |
+| Choose a tmux session or Codex app server to stop | `aifabrix agent-kit kill` |
 
 Use a different `--name` per workspace so several Claude or Codex sessions can run on the same host. Claude and Codex in the **same** folder also need two names.

package/templates/agent-kit/skills/shared/status.md

@@ -0,0 +1,85 @@
+# Status first — what a bare invocation does
+
+A skill named with no phase is a **question, not an instruction**. Report status, say what
+you would do next, and wait. This is the default for every lifecycle skill.
+
+## Read-only means read-only
+
+With no phase argument, you may read local packages, run `aifabrix auth status`, and run
+read-only inspection such as `show --online` and `list`. You may **not**:
+
+- upload, deploy, publish, or promote anything
+- advance a plan task or mark one done
+- create proof assets, Evidence, Knowledge, or tests
+- run assistant cases or any command that mutates external state
+
+Never infer a phase from "the safe next eligible one". Ambiguity is a reason to ask, not a
+licence to start. Read-only inspection is still allowed when the user names a phase that
+cannot run yet — report why instead of doing adjacent work.
+
+## Open by saying what you are about to do
+
+Before the first command of any phase, state in one line what the phase will change and
+what it will leave alone. A user who has not used this kit before cannot consent to work
+they cannot see coming.
+
+## Offer the route, do not choose it
+
+Ask once, with these options. Proceed only on an explicit choice.
+
+| Option id | Means |
+| --- | --- |
+| `route-normal` | Run the normal path for this skill through to its gate, stopping at each phase gate |
+| `route-check` | Inspect and test only — validation, checks and status, no publish or promotion |
+| `route-other` | Something else; ask what |
+| `next-stop` | Stop here |
+
+`route-normal` still stops at every phase gate and still needs `next-yes` to continue
+([interaction.md](../aifabrix-plan/references/interaction.md)). It is a route, not a
+licence to run the whole lifecycle unattended.
+
+## Always report the combined matrix
+
+Report every row, in this order, for any status, phase result, or completion claim. Use
+`UNKNOWN` for anything not measured — never omit a row and never fill one by inference.
+[delivery-verdict.js](../aifabrix-connected-system/scripts/delivery-verdict.js) computes
+the verdict rows from what you observed.
+
+| Row | Where the value comes from |
+| --- | --- |
+| Package | `aifabrix validate <key>` — `Validation passed!` / `Validation failed!` (`--format json` gives `valid`) |
+| Online | `aifabrix show <key> --online` — `Draft` / `Published` / `Archived`; `--json` returns the raw lowercase status |
+| AI Readiness | **no CLI surface** — record what the portal shows, or report `UNKNOWN` |
+| Operations | `aifabrix verify-operations <key> --json` — `verdict`, `operationalReadinessPercent` |
+| Trust | `aifabrix verify-trust <key> --json` — `verdict`, `aiTrustPercent` |
+| Governance | `aifabrix verify-governance <key> --json` — `verdict`, `policyCoveragePercent` |
+| Role Assistant | `aifabrix role-assistant test <roleKey> --json` — `verdict`, `certification`. **Availability is an operator action with no CLI surface**: confirm it explicitly or report `UNKNOWN` |
+| Prove readiness | computed — READY or BLOCKED |
+| Delivery | computed — overall verdict |
+
+Pillar verdicts are `VERIFIED`, `FAILED`, `NOT_VERIFIED`, `NOT_APPLICABLE` — never `PASSED`.
+`NOT_VERIFIED` is **not** a pass: it is where a pillar sits until it has been proved.
+Certification is a separate axis (`BRONZE`…`PLATINUM`, `TECHNICALLY_READY`…), never a
+substitute for a verdict.
+
+`READY`, `BUILT`, `PASS`, `PASS_WITH_SKIPS`, `NEEDS_FIXES` and `BLOCKED` are this kit's
+delivery vocabulary, not CLI output. Never quote them as if a command printed them.
+
+## Never headline a success the verdict does not support
+
+When Delivery is `NEEDS_FIXES` or `BLOCKED`, do not open with a bare `READY`, `BUILT`,
+`PASS`, or "all checks passed". Qualify every claim with its scope:
+
+```text
+Package: BUILT · Online: Draft · Operations: FAILED 60% · Delivery: NEEDS_FIXES · Prove: BLOCKED
+```
+
+A green package gate is a statement about files on disk. It says nothing about whether the
+system is published, whether it behaves correctly, or whether the business case is proven.
+
+## A known failure stays open
+
+A runtime, governance, persistence, or E2E failure remains active until **that same
+concern** is rerun and passes. Later structural or integration success does not clear it,
+and neither does a rerun of a different layer. Carry open failures into every subsequent
+status report until they are genuinely resolved.

package/templates/agent-kit/workspace/BUILDER_IMPROVEMENT_FINDINGS.md

@@ -0,0 +1,27 @@
+# Builder improvement findings
+
+Generic gaps in the Builder CLI, the Agent Kit skills, or the platform. Created
+once by `aifabrix agent-kit install` and owned by this workspace from then on;
+update never rewrites it.
+
+File a finding here instead of editing `.agents/skills/**`, which
+`aifabrix agent-kit update` rewrites. Never weaken a gate, assertion, or test to
+make a finding go away.
+
+Keep customer specifics out: no correlation ids, audit refs, internal URLs,
+tenant or record identifiers, hostnames, or customer names. A reader outside
+this workspace should still be able to act on it. Anything customer-specific
+belongs in `integration/<systemKey>/README.md` or the role's `learning.md`.
+
+Newest first.
+
+## YYYY-MM-DD — One line naming the gap
+
+Command: the exact command, with customer values replaced by placeholders.
+
+Observed: what happened, including the error text and the verdict.
+
+Expected: what should have happened, and why that is the reasonable behavior.
+
+Scope: whether this reproduces outside this workspace, and what is still
+unproven. Say so plainly when the root cause is not established.

package/templates/agent-kit/workspace/README.md

@@ -8,8 +8,21 @@ Vendor limits, credentials, designated test subjects, and PII live only in each
 
 ## How to start
 
+You can say **“Hi”** in a new agent chat. Describe the business process or
+role you want to improve and the result you need; a plain-language example is
+enough to start. The agent will map that context to Connected Systems, a Role
+Assistant, and a way to prove the result. It checks sign-in and existing
+systems before planning the work.
+
+| Claude Code / Cursor | Codex | What the skill guides |
+| --- | --- | --- |
+| `/aifabrix-plan` | `$aifabrix-plan` | Turn business context or a spec into a plan and identify missing facts |
+| `/aifabrix-connected-system` | `$aifabrix-connected-system` | Validate, build, test, and publish Connected Systems |
+| `/aifabrix-role-assistant` | `$aifabrix-role-assistant` | Create or update a catalog Role Assistant using published systems |
+| `/aifabrix-prove` | `$aifabrix-prove` | Prove a real business case and record the result |
+
 1. Open **this folder** in Cursor, Claude Code, or Codex. Host install and sign-in: **[AGENTKIT.md](./AGENTKIT.md)**.
-2. The agent checks `aifabrix auth status`. If you are not signed in, it asks for the Miso Controller URL and gives you a browser link. You do not need a terminal. Details: **[AGENTKIT.md](./AGENTKIT.md)**.
+2. Before planning or using online Builder commands, the agent checks `aifabrix auth status`. If you are not signed in, it asks for the Miso Controller URL and gives you a browser link. You do not need a terminal. Details: **[AGENTKIT.md](./AGENTKIT.md)**.
 3. In chat, either **invoke a skill** or **paste a prompt** from the tables below. Work in order. Wait for the gate (`PLAN_READY`, `READY`, `BUILT`, then `PASS` or `PASS_WITH_SKIPS`) before the next step.
 
 ### How to use prompts

package/templates/applications/builder-api/application.yaml

@@ -5,7 +5,7 @@ app:
   description: 'Business Transformation services — HTTP orchestration for connected-system workspace lifecycle via Dataplane Enterprise MCP and governance APIs.'
   type: webapp
   language: typescript
-  version: 1.0.0
+  version: 2.60.0
 
 # Image Configuration
 image:

package/templates/applications/dataplane/application.yaml

@@ -5,7 +5,7 @@ app:
   description: "AI Fabrix Dataplane is a secure, in-tenant integration and automation layer that supplies governed, normalized, and explainable enterprise data to AI agents. Using CIP as a declarative standard, it enforces RBAC and ABAC, executes integrations, and exposes trusted data via MCP and OpenAPI."
   type: webapp
   language: python # Explicitly specify Python language
-  version: 2.0.70
+  version: 2.0.74
 # Image Configuration
 # Set tag to match your build (example: aifabrix build dataplane -t 1.0.0).
 # Registry is required so the controller can pull the image (avoids docker-not-found on the controller host).
@@ -98,7 +98,35 @@ build:
 #   (never product OPENAI_* / AZURE_OPENAI_*). ≥2 providers →
 #   ENTERPRISE_LLM_DEFAULT_SELECTOR (portal/env deploy default); Environment
 #   Settings ai.llmProvider overrides without redeploy.
-# - ENVIRONMENT → set by deployment target
+# - ENVIRONMENT → resolved per environment below
+
+# =============================================================================
+# Environment Resolution
+# =============================================================================
+# One installation runs dev, tst and pro Dataplanes side by side
+# (environmentScopedResources: true), so these values vary by environment, not by
+# resource group. There is no `platforms:` section: nothing here depends on which
+# stack the installation is. env.template consumes the names as {NAME}.
+environments:
+  - environment: dev
+    configuration:
+      - name: ENVIRONMENT
+        value: 'dev'
+      - name: PIPELINE_ENV_KEY
+        value: 'dev'
+  - environment: tst
+    configuration:
+      - name: ENVIRONMENT
+        value: 'tst'
+      - name: PIPELINE_ENV_KEY
+        value: 'tst'
+  - environment: pro
+    configuration:
+      - name: ENVIRONMENT
+        value: 'pro'
+      # Empty keeps the existing behaviour: derive the key from MISO_CLIENTID.
+      - name: PIPELINE_ENV_KEY
+        value: ''
 
 configuration:
   # -------------------------------------------------------------------------