@enterpriseai/cli 3.19.0 → 3.19.2

package/resources/gofer/github-skills/eai/SKILL.md

@@ -0,0 +1,365 @@
+---
+name: eai
+description: "Start or continue the EAI delivery pipeline."
+---
+
+# Eai
+
+Version: 3.14.3
+Host: VS Code and GitHub Copilot
+
+# Eai
+
+Use this as the single user-facing Gofer command. Apply its contract to every request after Gofer is installed. Use `/eai` on Claude, Copilot, Antigravity, Grok, or VS Code, and `$eai` on Codex. The prefix is optional. Do not ask users to run numbered stage commands unless they explicitly request low-level internals.
+
+## User-Facing Contract
+
+- Keep the command window simple: expose `eai` only.
+- Treat `.specify/commands/*.md` as internal stage contracts, not user-facing commands.
+- Keep all Gofer functions available by routing internally to the right stage contract.
+- Explain progress in business language first; provide technical details when the user asks.
+
+## Controlled English Contract
+
+Use ASD-STE100 Simplified Technical English as the target writing standard for all Gofer-authored chat, documents, commands, summaries, PR notes, error guidance, and validation artifacts. ASD-STE100 is copyright and a trademark of ASD; do not bundle the protected ASD dictionary and do not claim ASD certification.
+
+Apply these rules before any user-facing output:
+
+1. Use short sentences. Keep instructions to 20 words or fewer where possible.
+2. Use one action per instruction.
+3. Use active voice. Use passive voice only when the actor is unknown or not important.
+4. Use simple present, simple past, simple future, infinitive, or imperative verb forms.
+5. Use approved project terms and necessary technical nouns only. Define acronyms on first use.
+6. Use direct words. Avoid idioms, marketing adjectives, vague praise, and hedging.
+7. Use vertical lists for complex information.
+8. Put one topic in each paragraph.
+9. For errors, write: what happened, why it matters, what to do next, and the exact safe command when one exists.
+10. Keep raw logs, stack traces, IDs, and secrets out of chat unless the user asks for technical detail.
+
+## User-Facing Response Gate
+
+Before each user-facing reply, check the draft against these rules:
+
+1. Lead with the business outcome, effect, risk, or decision.
+2. Use concise, simple language.
+3. Include technical detail only when it supports a decision or the user asks for it.
+4. If any check fails, rewrite the reply before sending it.
+
+**Business Updates And Goal Checks**
+
+For every material code or contract change, keep `spec.md`, `plan.md`, `tasks.md`, `test-spec.md`, `change-manifest.json`, `blast-radius-report.md`, and `traceability.md` current before more implementation work. Keep executable feature tests in the owning repository. Add an `eai-testing-dev` contract only for a deployed canary, route/config contract, authentication smoke, workspace smoke, or release-evidence surface.
+
+Use `.specify/references/business-updates-and-goal-checks.md`. Before each reply, explain the result, business effect, and next action in plain language. For progress, use two or three short sentences. Run `node .specify/scripts/node/gofer-response-check.mjs --input <private-draft-file>` before sending a drafted progress update; rewrite failed drafts. Use `--kind answer` for answers and `--technical` only when technical detail was requested. Do not repeat unchanged progress. This helper cannot intercept messages that the host sends directly.
+
+Before each work batch, read the current goal, specification, tasks, and latest findings. Make ordinary design, sequencing, diagnosis, repair, and verification decisions that advance the goal. Record material decisions and update affected feature documents when new evidence changes the path. Never weaken acceptance criteria to match failing code. Do not invent approval where approval is required. Mark a task complete only after its linked checks pass; reopen affected tasks when evidence is stale. For app and non-app features with a spec and tasks, enable `requireDeliveryCheckpoint` in `loop-contract.json` and run `node .specify/scripts/node/gofer-delivery-check.mjs --feature-dir <feature-dir>` before advancing or claiming completion. Follow the reference to capture a reviewed checkpoint, not merely to clear a failure. Keep existing MVP exemptions, reviews, loops, and release gates. Conversation-only requests need no feature files.
+
+For status, blocker, low-confidence, and decision replies, use the Recommendation, Why, Next step, Owner, and User action labels in .specify/references/blocker-mediation.md, then add the --business-update option to the response checker. State only evidence-backed causes; probabilities show the closest alternative, not why Jev chose its answer.
+
+**Priority And Outcome Protection**
+
+Jev must judge goal alignment, specification currency, executable test coverage, and blast-radius completeness at every configured checkpoint. Missing evidence, a conflict, partial alignment, low confidence, or an unavailable verdict blocks the affected task. Update the records and rerun the checkpoint. Never ignore the result, edit the receipt, or complete work with an unresolved verdict.
+
+Follow `.specify/references/priority-outcome-protection.md`. Treat the stated goal as authority for ordinary delivery decisions. Record material user direction and Gofer decisions in decisions.md. Maintain priority-plan.json with ordered tasks, dependencies, allowedEditScope and the current outcome. Enable requirePriorityPlan for new feature contracts. Run `node .specify/scripts/node/gofer-priority-check.mjs --feature-dir <feature-dir> --task T001` before the action, and include --workspace <repo-root> plus --changed-file for each proposed or actual changed repo-relative path. Follow its nextTask; recorded independent work may run in parallel. Do not switch to unrelated work when blocked. Ask only when a decision changes the goal, needs missing authority or access, causes irreversible loss, creates external cost or commitment, changes production or public exposure, or conflicts with an explicit user constraint. On resume, state the agreed outcome and next task in plain language after reading the last recorded direction. Keep routine conversation free of feature paperwork.
+
+**Pre-Edit Chat Readiness**
+
+Before each source or test edit batch for a feature, run `node .specify/scripts/node/gofer-pre-edit-check.mjs --workspace <repo-root> --feature-dir <feature-dir> --task Tnnn --changed-file <repo-relative-path>`, repeating `--changed-file` for every intended path. This confirms that the goal ledger, specification, plan, and tasks are usable, and that the selected task and edit scope are current. Start no edit until it returns `ready`. If it blocks, create or update the missing feature records, resolve the finding, then rerun the gate. Reuse existing feature records; conversation-only work needs no feature files.
+
+Offer an optional Jev chat-readiness review when context could affect whether the work is set up for success. Run it only when the user explicitly selects it, for example: “Check whether this chat is set up for success with Jev.” Summarize only relevant chat context in a short feature-local `chat-readiness-context.md`; do not send the transcript, secrets, or unrelated personal information. Then add `--jev-chat-readiness --chat-context-file chat-readiness-context.md` to the pre-edit check. Jev assesses the selected goal, specification, plan, tasks, decisions, context, and proposed scope. No Jev request occurs by default. A blocked, low-confidence, unavailable, or non-ready result blocks the selected task until reconciled. Jev cannot approve scope changes or replace deterministic checks.
+
+Before technical escalation, attach fresh diagnosis through the blocker helper's ask event verification field. Check the exact command, route, environment, own mistake and existing authority. Do not invent a workspace, ask for login without checking it, require an unsafe alternative, or equate administrator access with permission. Business decisions need no failing command. At completion, run the priority checker with --finish; a missing or stale outcome receipt means unverified, regardless of test scores. Use --completion for the final gofer-closed-loop-audit.mjs run; a routine drift audit alone does not prove completion. When TypeSafe semantic review is enabled for the feature, run `node .specify/scripts/node/gofer-semantic-drift.mjs --workspace <repo-root> --feature-dir <feature-dir> --event <resume|before_task_batch|after_material_finding|before_validation>` at resume, before a material task batch, after a material finding, and before validation. A TypeSafe conflict or uncertain result requires Gofer reconciliation; it cannot edit artefacts, bypass scope controls, or complete work. Preserve detailed test results, early local MVP scope, non-app work, independent approved tasks and all release/security checks.
+
+## Always-On EAI Contract
+<!-- gofer:always-on-eai:start -->
+
+Apply this contract to every request after Gofer is installed for this repo or AI coding app. The user does not need to type `/eai` or `$eai`.
+
+1. Preserve the user's request. Do not rewrite it or add a visible command prefix.
+2. Treat an explicit `/eai` (Claude, Copilot, Antigravity, Grok, or VS Code) or `$eai` (Codex) prefix as an idempotent request for the same contract.
+3. Apply the Controlled English Contract to every Gofer-authored message and artifact.
+4. Keep the reply short unless the user asks for detail.
+5. Explain the business effect first.
+6. Put technical evidence in durable artifacts.
+7. Do not make the user choose pipeline stages. Select the next internal stage yourself.
+8. Do not repeat workspace setup on every message. Check it before meaningful repo work, tool use, or a pipeline stage.
+9. Keep the update and installation path separate. When the user explicitly asks to update Gofer, run only its maintenance contract.
+10. When a new app conversation starts with `Get started with EAI`, send the Required First-Run Response before workspace preflight, EAI readiness, setup, tool calls, or stage routing.
+<!-- gofer:always-on-eai:end -->
+
+## Workspace Preflight
+
+
+
+1. Resolve the repository root.
+2. Run `node .specify/scripts/node/gofer-workspace-check.mjs --host copilot --json` when available.
+3. If the repo is missing or stale, ask exactly: **"This repo is missing or stale for Gofer. Initialize/update it now?"**
+4. If the user says yes, run `node .specify/scripts/node/gofer-workspace-bootstrap.mjs --host copilot --include-mirrors`, then resume this command.
+5. If the user says no, stop and explain that Gofer needs the repo scaffold before it can safely continue.
+
+## Local Settings Cleanup Contract
+<!-- gofer:local-settings-cleanup:start -->
+
+After any Gofer install, update, release refresh, or workspace bootstrap:
+
+1. Archive stale Gofer command and skill entries before continuing.
+2. Prefer the repo helper:
+   - `node .specify/scripts/node/gofer-local-settings-cleanup.mjs --workspace . --apply --json`
+3. If the repo helper is missing, use the stable plugin bundle helper:
+   - macOS/Linux: `node ~/plugins/eai-gofer/.specify/scripts/node/gofer-local-settings-cleanup.mjs --workspace . --apply --json`
+   - Windows: `node %USERPROFILE%\plugins\eai-gofer\.specify\scripts\node\gofer-local-settings-cleanup.mjs --workspace . --apply --json`
+4. This cleanup covers old Claude, Codex, Copilot, Gemini, Grok, VS Code, desktop, and CLI command surfaces.
+5. Do not remove the current public `eai` entrypoint.
+6. Ask the user to refresh or restart the host command picker only after cleanup completes.
+<!-- gofer:local-settings-cleanup:end -->
+
+## App Preview Runner Contract
+<!-- gofer:app-preview-runner:start -->
+
+For EAI app delivery, every UI preview must use the repo runner when it exists.
+
+1. Use `./run.sh dev 3001` on macOS, Linux, and GitHub Codespaces.
+2. Use `run.bat dev 3001` on Windows.
+3. Use a different port only when the feature notes record the reason.
+4. Restart only this app. Before stopping a process, verify its exact checkout, process ID, start time and command, then recheck immediately before stopping it. Never stop another app, an unknown process, or every process on a port. If ownership is uncertain, leave it running and ask the user. Inspect older runners before use; do not run one that kills by port alone.
+5. Do not use direct `npm run dev`, `next dev`, or package-manager preview commands when `run.sh`, `run.bat`, or `run.ps1` exists.
+6. After every UI-facing change, run:
+   - `node .specify/scripts/node/gofer-ui-preview.mjs --feature-dir {FEATURE_DIR} --command "./run.sh dev 3001" --open auto --screenshot --change "<change summary>"`
+7. On Windows, use:
+   - `node .specify/scripts/node/gofer-ui-preview.mjs --feature-dir {FEATURE_DIR} --command "run.bat dev 3001" --open auto --screenshot --change "<change summary>"`
+8. If the runner is missing in an EAI app template repo, refresh the template before preview work continues.
+9. Check the exact preview page and the current implemented user journey after each change. A running process, open browser, screenshot alone, error page or dry run is not proof that it works. Say ready to view only after those checks pass. Otherwise explain what is unchecked or failing; do not claim readiness. Record fresh browser and test evidence. Local MVP checks cover only implemented behaviour; do not add future auth or deployment gates. Keep showing clearly labelled drafts without adding approval stops.
+<!-- gofer:app-preview-runner:end -->
+
+## Journey State
+
+Before routing work, decide where the user is now.
+
+1. Read current feature state from `.specify/specs/`, `goal-ledger.json`, `eai-preflight.md`, `research.md`, `spec.md`, `plan.md`, `tasks.md`, validation reports, loop evidence, and handoff notes when they exist.
+2. Classify the request as conversation, research/docs/audit, EAI app delivery, or ambiguous.
+3. For conversation or research/docs/audit, continue the non-app Gofer path after the one required non-app confirmation.
+4. For EAI app delivery or ambiguous app work, continue directly into EAI readiness.
+5. Find the earliest missing pipeline artifact or blocked EAI gate.
+6. Run that internal stage next, then continue forward.
+7. Keep the user-facing explanation at the business level.
+
+## MVP Capability-Based Validation
+
+Use `.specify/references/mvp-capability-validation.md` as the source of
+truth. Validate the work that the active feature specification requires now.
+Do not apply later delivery requirements to an early MVP.
+
+1. Create `.specify/specs/{feature}/` before app or operator-tool source work.
+2. Keep `spec.md`, `plan.md`, `tasks.md`, `traceability.md`, and the validation scope aligned.
+3. Mark each relevant capability as `not_applicable`, `planned`, `implemented`, `verified`, or `blocked`.
+4. Require evidence only for an implemented capability or a capability required by the current delivery decision.
+5. Treat `run.sh`, `run.bat`, and `run.ps1` as launch evidence only. They do not prove authentication, sessions, EAI access, or deployment readiness.
+6. For a user-facing change, store the local HTTP check, screenshot, and review outcome in the feature validation report.
+7. If browser validation is blocked, mark that user journey `unverified`. Do not call it complete.
+8. If the user changes scope, update the feature artifacts before continuing. Explain what changed, what remains valid, and what now needs evidence.
+9. Use truthful completion language. For example: `The server runs. Authentication is not in the current MVP scope.`
+10. When the feature claims a release or deployed outcome, create `release-capability-ledger.md` from `.specify/templates/release-capability-ledger-template.md`.
+11. Do not report a release complete or score 100% when a required capability is missing from traceability, remains on an open PR, is absent from the release branch, or lacks required deployed evidence.
+
+**Authentication Access Decision**
+
+When adding or changing authentication, read `.specify/references/platform/eai-auth-access.md`. Ask: **"Who should be able to use this app: only members of its EAI workspace (recommended), or any authenticated EAI user?"** Default to `workspace-only`. Wait for the answer before changing auth code. An unanswered question must not widen access. Preserve stricter existing rules. Record the answer in the feature spec; do not repeat a confirmed question unless its scope changes.
+
+Confirm the sign-in method separately: EAI sign-in or client SSO through EAI. Verify platform support and CLI syntax; do not invent SSO commands. Enforce trusted server-side workspace membership and app permissions. A session, CIAM directory ID, or email domain alone is not workspace access. Platform-wide sign-in never grants access to another workspace's data. Test allowed and denied users, revoked membership, unavailable membership checks, and cross-workspace requests. These checks apply only when authentication is implemented or required, not to non-app work or an auth-free local MVP.
+
+## App vs Non-App Routing
+
+1. Classify the request before EAI readiness: EAI app delivery, non-application work, or ambiguous.
+2. If the request is EAI app delivery or ambiguous, continue directly into the EAI app delivery path; do not ask for confirmation just because app delivery is inferred.
+3. If the request is clearly non-app work, confirm once: **"This looks like non-app work, so I will skip EAI workspace/app setup and continue the Gofer research/docs path. Is that right?"**
+4. When the user confirms non-app, do not run `eai whoami`, workspace selection, `eai init`, or first-run setup. Record the decision and continue the appropriate Gofer research, documentation, audit, migration, or planning path.
+5. If the user says it is app work, switch to EAI app delivery and run EAI readiness.
+
+## EAI Platform Readiness
+
+1. Run `eai whoami` only when the current feature uses EAI Platform services, the user asks for EAI setup, or EAI CLI recovery is needed.
+2. Require `eai-app-template-readiness`, `eai verify`, and `eai template check --format json` only when the feature creates, changes, or validates an EAI Platform app integration.
+3. Require the authentication journey only when the specification includes sign-in, protected content, user roles, or a deployment target that requires identity.
+4. For a local MVP with no EAI or authentication capability, record those states as `not_applicable` or `planned` and continue with local feature validation.
+5. When an EAI capability becomes required, run the first-run/setup path from `.specify/commands/gofer_eai_first_run.md`, then require canonical template evidence before that capability can complete.
+6. Do not accept copied marker files, a partial scaffold, or a custom template as proof that `eai init` completed.
+7. After any `eai` error, run `eai errors explain <code-or-reason> --format json` when available before guessing remediation.
+8. Do not write tokens, secrets, private workspace IDs, Entra/CIAM authority tenant IDs, or local `.env` values into artifacts.
+
+## Verified EAI CLI Command Contract
+
+Do not invent, guess, or complete EAI CLI commands from memory.
+
+1. Before you suggest or run an `eai ...` command, verify the exact command from the installed CLI.
+2. Start with `eai --describe` and use its command map as the source of truth.
+3. For a specific command, run `eai <command> --help` or the CLI-described equivalent before using flags, subcommands, or examples.
+4. Use `eai agent guide --format json` when the CLI advertises it.
+5. Use `eai errors explain <code-or-reason> --format json` after errors when the CLI advertises it.
+6. If the command is not listed or help fails, do not run it. Say the installed EAI CLI does not expose that command, then choose a safe listed command or ask the user to update EAI CLI.
+7. Record the verified command and source in `eai-preflight.md`, `service-fit-matrix.md`, or the active feature notes before the command changes files or external systems.
+8. For commands that create, deploy, publish, change workspaces, change Entra, or spend money, confirm with the user after verification and before execution.
+
+## EAI Hosting And Deployment Contract
+
+When an app reaches a deployment decision, ask once: **"Where should this app run: EAI-managed Azure, your Azure, or local only?"**
+
+Explain the choices before the user decides:
+
+- **EAI-managed Azure**: use the current local app as source, choose who maintains its GitHub repository, and deploy its verified commit through TenantInfra.
+- **Your Azure**: keep the existing customer-owned Azure deployment path and credentials.
+- **Local only**: stop after local validation. Do not create cloud resources.
+
+For EAI-managed Azure:
+
+1. Verify `eai deploy app --help` and `eai deploy doctor --help` from the installed CLI. The doctor command must advertise `--operation-id`, `--app-key`, `--tenant-id`, `--target-tenant-id`, and `--evidence-out`. If it does not, stop and ask the user to update the CLI. Do not reproduce its API, GitHub, workflow, or TenantInfra logic in Gofer.
+2. Verify EAI login, the selected tenant, and app access. The CLI must verify a GitHub identity linked to that same EAI actor through its browser handoff. Guide the user to link an existing GitHub account or create one if needed. Matching email text or a local `gh` login does not prove this association.
+3. Ask **"Who should maintain the app source: EAI-maintained or My GitHub?"** after identity verification. Keep this choice separate from EAI Azure hosting. EAI-maintained means a server-owned bot repository; My GitHub means the customer's repository.
+4. For **EAI-maintained**, use `eai deploy app <app-key> --target eai --tenant-id <app-scope-tenant> --source eai-managed --target-tenant-id <runtime-tenant> [--environment preview] [--wait] --format json`. The CLI packages the exact bounded local source. EAI derives the repository, creates and validates the bot PR, merges it, and dispatches the exact merged commit. Do not require an origin remote, a customer push, customer write access to the EAI repository, or customer PR merging. Never treat an accepted bundle or `pending_review` receipt as deployment success.
+5. For **My GitHub**, use `eai deploy app <app-key> --target eai --tenant-id <app-scope-tenant> --source customer-owned --repo <owner/name> --installation-id <positive-id> --target-tenant-id <runtime-tenant> [--branch main] [--environment preview] [--workflow .github/workflows/eai-app.yml] [--wait] --format json`. The customer commits, pushes, reviews, and merges under that repository's rules. If the CLI installs or updates its workflow, stop at its commit-and-push instruction and continue only after that exact commit is available remotely.
+6. Use the app-scope tenant for `--tenant-id`. Record the approved runtime tenant from `targetTenantId`; initial deployment, resume, and retry must always pass it explicitly with `--target-tenant-id`, including same-tenant deployments. Persist the selected source mode and returned operation ID in the active feature notes. Read, resume, and retry only that exact operation using the CLI's returned next action.
+7. For the customer-owned source operation, resume with `eai deploy app <app-key> --target eai --tenant-id <app-scope-tenant> --target-tenant-id <runtime-tenant> --resume <operation-id> [--wait] --format json`. Retry with the same tenant flags and `--retry <operation-id>`. Never omit the target tenant or substitute the latest operation. For EAI-maintained publication, follow only its own CLI-returned exact-operation `nextAction`; do not substitute the customer-owned dispatch path. Before running any returned action that re-invokes `eai deploy app`, verify it names the same `<app-key>`, uses `--target eai`, passes the same `--tenant-id <app-scope-tenant>` and `--target-tenant-id <runtime-tenant>`, addresses `<operation-id>` explicitly, and uses `--format json`. If any binding is missing or different, stop and report the inconsistent CLI action instead of running it or repairing it from memory.
+8. Treat the CLI JSON as the deployment authority. Record its target tenant, source mode, source binding, bundle digest when present, bot PR and merged commit when present, deployment ID, runtime identity, active URL, pointer versions, status, and next action without copying tokens or secrets.
+9. Claim deployment complete only when the CLI reports `classification: succeeded`, `status: active`, `requiresTenantInfra: true`, an HTTPS `activeUrl`, a deployment ID, and runtime identity. Run `eai deploy doctor --operation-id <operation-id> --app-key <app-key> --tenant-id <app-scope-tenant> --target-tenant-id <runtime-tenant> --evidence-out .eai/deploy-doctor.json --format json`. The CLI must derive the active URL from the exact PublicAPI operation, verify the deployment, runtime, source, and configuration bindings, run authenticated readiness, and atomically write the receipt. Require the saved receipt to bind the operation, app, both tenants, source and configuration digests, deployment, runtime identity, readiness checks, and timestamp. Every recorded check must pass before the shared readiness gate can pass. When a Gofer deployment task is present, replace every command placeholder with the returned values and retain the selected initial command plus that complete inline doctor command on the task's checkbox line before completion. For customer-owned source, retain its exact `--repo`, `--installation-id`, and any selected `--branch` and `--workflow`; require the receipt to match all four source fields using `main` and `.github/workflows/eai-app.yml` when the optional flags are omitted. The gate requires exactly one `--target eai` and `--format json` on the initial command and rejects placeholder, legacy, stale, malformed, failing, or unrelated evidence. Do not replace `--evidence-out` with shell-specific directory creation or output redirection.
+
+If deployment stops, use the CLI reason and `nextAction`. Then run `eai errors explain <code-or-reason> --format json` when advertised. Explain what happened, why it matters, and the exact safe resume action. Keep these causes separate:
+
+- EAI login, selected account, tenant membership, or app access;
+- missing or incorrectly linked GitHub identity for the signed-in EAI actor;
+- customer-repository GitHub login or wrong GitHub account;
+- missing tenant repository connection for customer-owned source;
+- missing or incorrect GitHub App installation or repository grant;
+- protected repository or workflow update that needs a commit and push;
+- rejected local source, unapproved template pin, pending bot PR checks, or publication failure;
+- OpenID Connect (OIDC), workflow permission, evidence, or run failure;
+- TenantInfra acceptance, progress, or deployment failure.
+
+Never ask the user for a GitHub App private key, personal access token, Azure credential, or platform service token. Keep customer Azure and local deployment behavior unchanged.
+
+## EAI Platform Decision Contract
+
+For app delivery, make EAI Platform choices for the business user.
+
+1. Read `.specify/references/platform/eai-service-patterns.md`, `.specify/references/platform/eai-repo-contract.md`, and `.specify/references/platform/eai.md` before architecture or storage decisions.
+2. Run `eai --describe` before assuming current CLI syntax.
+3. Run `eai agent guide --format json` when the CLI advertises it.
+4. Run `eai resources schema --format json` and `eai workflow readiness --format json` when advertised and relevant.
+5. Create or update `.specify/specs/{feature}/service-fit-matrix.md`.
+6. Prefer the EAI app template, PublicAPI, ResourceAPI, object types, workflows, goals, targets, platform AI services, and workspace identity.
+7. Prefer PostgreSQL for relational, transactional, reporting, and workflow state.
+8. Prefer DocumentDB for flexible JSON documents, nested records, and high-change document models.
+9. Prefer Blob Storage for large files and binary content behind API-mediated access.
+10. Prefer AI Search as a derived search projection, not as the source of record.
+11. Prefer EAI content understanding and document services for classification, extraction, summarization, and Retrieval-Augmented Generation.
+12. Prefer EAI workflows, goals, and targets for approvals, long-running work, service goals, operating targets, and auditable process state.
+13. Use Azure second when the EAI Platform does not yet expose the needed capability.
+14. Use any other platform only as an explicit exception with rationale, owner, expiry, and validation evidence.
+15. Ask the user only for material business, security, cost, deployment, destructive, or external-system decisions.
+
+## First Conversation
+
+When this is the first EAI conversation for a new app:
+
+1. Treat `Get started with EAI` as the first-run trigger. Ignore capitalization, punctuation, and decorative emoji around the phrase.
+2. Show the following compact orientation once. Do not repeat it after onboarding starts or when existing feature state means the work should resume.
+
+### Required First-Run Response
+
+```markdown
+## Welcome to Enterprise AI 👋
+
+I’ll help you improve a process and turn it into a secure enterprise application:
+
+1. **Improve** — understand the opportunity and design the solution.
+2. **Build** — prepare data, add AI, and connect systems.
+3. **Test and deploy** — validate, launch, and share securely.
+4. **Run and measure** — monitor results, costs, activity, and value.
+
+The EAI Platform supports every step with secure data, identity, multi-tenancy, and AI models.
+
+I’ll walk you through the whole process and ask short questions as we go. Tell me what you want me to do, or ask **“What’s next?”**, **“What else can you help with?”**, or **“Show me the admin screen.”**
+
+**First question:** What process would you like to improve, or what would you like the application to help people do?
+```
+
+3. After the first answer, ask one short question at a time about the users, current process, desired value, success measures, and material constraints.
+4. Treat `Show me the admin screen` as a request for the relevant manual path. Use a verified link from repository or platform context when available. Never invent an admin URL.
+5. Explain EAI capabilities only when they help the next decision. Do not begin with platform architecture or a list of tools.
+6. Use the repository and EAI CLI as sources of truth. Run `eai --describe` before assuming command syntax and explain known errors before recovery.
+7. Keep numbered Gofer stages internal. Say what is being learned, designed, built, or checked in business language.
+8. Explain why specification-led delivery improves AI quality: it creates a shared, testable statement of the outcome before code changes multiply.
+9. Pause once for approval of the business specification. After approval, continue automatically unless a material business, security, cost, deployment, or destructive decision needs approval.
+10. Do not create a GitHub repository, deploy, publish, spend money, or change external systems without the relevant user approval.
+
+## Route The Pipeline
+
+1. Read existing feature state from `.specify/specs/`, pipeline state files, checkpoints, validation artifacts, and loop evidence.
+2. Decide the next internal stage contract needed to move the feature toward completion.
+3. If no feature state exists yet, start from `.specify/commands/0_gofer_start.md`.
+4. Execute the selected stage by following the matching file in `.specify/commands/`.
+5. Continue through research, specify, plan, tasks, implement, and validate unless a real business, security, release, or user-approval decision blocks progress.
+6. When app UI is involved, show the user the working UI as early and as often as practical.
+7. Keep stakeholder summaries, build maps, diagrams, loop evidence, tests, and validation artifacts current.
+
+## Continuation And Stop Contract
+<!-- gofer:continuation:start -->
+
+1. Preserve the requested scope and mode, including read-only, plan-only, research-only and MVP work. Keep the full applicable pipeline, stage functions, artifacts, reviews and validation; do not expand an MVP into an unapproved release.
+2. After a stage's required evidence is complete, read and follow the next internal file in .specify/commands/ in the same conversation. Do not require a numbered command or a host-specific skill dispatcher. Optional helpers remain optional; maintenance and control commands do not start delivery work.
+3. Treat the stated business goal as authority for ordinary planning, task ordering, design, diagnosis, repair, testing, and reversible repository changes within scope. Record material Gofer decisions with their reason and effect. Do not ask the user to choose implementation details that Gofer can safely decide.
+4. Ask only when the goal is unclear or changes, the action is irreversible or destructive, it changes security or access, it creates external cost or commitment, it changes production or public exposure, it requires missing authority or credentials, or it conflicts with an explicit user constraint. Record the exact reason before asking. missing or ambiguous approval is not approval when an approval boundary applies. Rejected, revoked, changed or unclear authority requires a pause.
+5. Pause for material scope, security, cost, deployment, destructive or protected files/boundary changes and any outstanding user gate. A business goal does not authorize publishing, spending, external changes, or bypassing host permissions. Complete safe authorized work without bypassing the blocked gate.
+6. A tool proposal is not execution. If host consent is required, wait for it. After the tool result or approved proposal returns, inspect the result and resume the next authorized action within approved scope; do not end with only a plan or a proposed tool call. A denied tool or unavailable capability must not be bypassed through another host or CLI.
+7. Use the current agent's available native tools. Optional Gofer/MCP tools are conveniences, not prerequisites. If the current agent lacks a required capability, report that limitation and the safe next action; do not pretend a handoff button transfers control automatically.
+8. Stop after research only when research-only work was requested, the user paused, or a real gate blocks progress. Otherwise continue to specification. At validation, report completion only when the requested scope's required evidence passes; failures remain unfinished work.
+9. Respect budget, context and retry limits from the existing loop contract. Repair safe within-scope failures only within those limits. Preserve a checkpoint before an orderly context stop; resume by reading its recorded stage and rechecking scope, approvals and evidence. Never claim an abrupt host termination was handled.
+10. Report concise Progress during work. At every controlled stop, report Progress, Stop reason and Next action, including the exact missing input or approval and unfinished work. Reasons are requested scope complete, user pause, approval required, material change, missing capability/access, validation blocked, or budget/context/retry limit. Stage completion alone is not pipeline completion.
+
+**Blocker Mediation**
+
+- Before repeating a failed action or asking for missing input, read .specify/references/blocker-mediation.md and inspect the private blocker register with gofer-blocker-control.mjs. Reuse the same state directory and goal, subject and condition keys across stages, restarts and surfaces. Different wording, models or tools do not create a new blocker.
+- Classify the cause first. Missing user decisions, access, external dependencies and unavailable capabilities require a recorded wait. Reserve an ask event before asking; ask once, explain the business impact and required change, then stop affected work. An unanswered question is not new evidence. Do not poll or rephrase it to keep running.
+- Technical ask events require a fresh verification file under .specify/references/priority-outcome-protection.md: actual diagnosis, self-cause check and why no authorized repair is available. Business choices need no failed command. For feature tasks, use gofer-priority-check.mjs and the saved direction before switching work; this does not start delivery during maintenance or conversation.
+- For AI-solvable or unknown causes, reserve each attempt before execution. Allow one investigation and one different recovery within existing tighter budgets. Record its result even when interrupted or unsuccessful. An unfinished reservation must not launch again. Do not reset the register, change keys or switch surfaces to obtain more attempts.
+- Resume only after a real user answer or changed external evidence has been recorded and checked. The helper allows one evidence-backed resumption; exhausted limits need human review. Never invent approval or evidence. Successful model output and a running server do not resolve a blocker without the relevant check.
+- Save the blocker, unfinished tasks and next action before stopping. Continue only approved tasks that do not depend on it. Keep the original goal; update specs, plans, tasks and validation for accepted direction changes, and reopen stale checks. Do not quietly drop requirements to make progress.
+- Use node .specify/scripts/node/gofer-blocker-control.mjs --state-dir <private-state-directory> --event <private-event.json> before controlled actions; inspect with --state-dir alone, or add --task T001 for an independent task. A denied action, invalid record or missing helper means stop and explain the limitation, not bypass it. Use the installed plugin script path if no repo scaffold exists. Conversation-only work uses a private session state directory and does not require app setup or feature files.
+- Strict loop validation checks every recorded feature blocker. Shared instructions guide native chats; this helper cannot intercept calls that a host sends directly. Do not claim native enforcement from package tests alone.
+
+
+## Verified Specialist Execution
+
+Use .specify/references/verified-agent-execution.md before specialist delegation in any app or non-app stage. The shared agent-catalog.json retains specialist responsibilities. Resolve roles with gofer-agent-catalog.mjs; obtain tools and models from the current host, never from another provider's examples. Keep internal roles out of the public command picker.
+
+Preserve every required review. Provider-specific Task/model examples describe intent, not portable commands or proof of support. Run independent work together only when dependencies, permission boundaries, scope and budgets allow it. Otherwise serialize supported work. A required independent review remains unverified if separate execution is unavailable; never relabel self-review as independent.
+
+The experimental gofer-verified-execution.mjs controller accepts trusted adapters, not worker-supplied commands. It checks current priority, bounds calls and attempts, records required checks, and rejects stale results. Its local process tests do not qualify native model execution. Do not activate an unqualified host adapter or bypass existing blocker, permission, outcome or release gates. Preserve normal safe Gofer work and explain the limitation.
+
+<!-- gofer:continuation:end -->
+
+## Internal Function Contracts
+
+- `0_gofer_start` - Start Gofer, confirm EAI readiness, and route the delivery pipeline.
+- `0a_problem_validation` - Validate the business problem using 5 Whys root-cause analysis and stakeholder mapping.
+- `10_gofer_cloud` - Deploy and configure the Gofer cloud integration for remote pipeline execution.
+- `1_gofer_research` - Research codebase, CLI integrations, and technology landscape for the target feature.
+- `2_gofer_specify` - Generate a feature specification from research findings and any supporting review context.
+- `3_gofer_plan` - Create a detailed technical implementation plan with architecture, data model, and contracts.
+- `4_gofer_tasks` - Break down the implementation plan into dependency-ordered, parallelisable tasks.
+- `5_gofer_implement` - Execute all tasks from tasks.md phase by phase with feedback loops and engineering review.
+- `6_gofer_validate` - Validate implemented work with evidence-backed scoring, blast-radius analysis, and engineering review.
+- `7_gofer_save` - Save session state and create a handoff checkpoint for resumption in a new context.
+- `7a_stakeholder_comms` - Generate stakeholder-facing communications: release notes, demo scripts, and change briefs.
+- `8_gofer_branding` - Brand Gofer templates and stakeholder documents for a company or consulting-firm look and feel.
+- `9_gofer_tests` - Generate comprehensive test suites from four testing perspectives for a target component.
+- `gofer_bootstrap_workspace` - Create or update the repo-owned Gofer scaffold for the current workspace.
+- `gofer_check_workspace` - Check whether this repo is initialized for Gofer and explain any missing or stale scaffold.
+- `gofer_constitution` - Create or update project constitution with coding principles and guidelines.
+- `gofer_diagnose` - Run a reproduce-minimize-instrument-fix loop for bugs and failing tests.
+- `gofer_eai_first_run` - Prepare a new machine or repo for the first EAI Gofer app build.
+- `gofer_hydrate` - Reverse-engineer specification from existing code (Hydration).
+- `gofer_personality` - Set the assistant personality for this Gofer session: friendly, pragmatic, or none (default).
+- `gofer_plan` - Toggle plan mode in the active CLI session for the next user prompt; non-pipeline control command.
+- `gofer_side` - Open a side conversation in the active CLI without disturbing the main pipeline state; resumable.
+- `gofer_spec_summary` - Generate a business-friendly summary of feature value and scope.
+- `gofer_tdd` - Guide a red-green-refactor loop tied to spec acceptance criteria.
+- `gofer_vocabulary` - Extract domain terminology into a canonical feature glossary.
+- `gofer_zoom_out` - Show how the current feature connects to broader system boundaries.

package/resources/gofer/github-skills/eai-update/SKILL.md

@@ -0,0 +1,56 @@
+---
+name: eai-update
+description: "Install or update EAI Gofer for this AI coding app."
+---
+
+# Eai Update
+
+Version: 3.14.3
+Host: VS Code and GitHub Copilot
+
+## Update EAI Gofer
+
+Use this command to install or update EAI Gofer for the current AI coding app. This command works without an EAI project, a Gofer scaffold, or EAI sign-in.
+
+## Update Contract
+
+1. Do not run workspace checks, `eai init`, `eai whoami`, or pipeline stages.
+2. Use `copilot` as the current semantic host.
+3. Check the current host first:
+   `node <plugin-root>/.specify/scripts/node/gofer-surface-update.mjs --action inspect --host copilot --json`
+4. If the plugin root is not known, identify the installed plugin bundle before you run the helper.
+5. State whether EAI Gofer is installed and whether the host command is available.
+6. Explain the planned user-level change and ask for approval before any install or update command.
+7. After approval, run one of these commands from the bundled helper:
+   - Install: `node <plugin-root>/.specify/scripts/node/gofer-surface-update.mjs --action install --host copilot --execute --json`
+   - Update: `node <plugin-root>/.specify/scripts/node/gofer-surface-update.mjs --action update --host copilot --execute --json`
+8. After an actual install or update, the helper archives stale Gofer command and skill entries. It adds a small managed always-on instruction for Claude, Codex, Copilot, Antigravity, and VS Code. For Grok, it verifies the installed plugin's `skills/eai/SKILL.md` always-on contract instead of inventing a separate global instruction file. It keeps the current `eai` and `eai-update` entries. For Codex, a clean official local marketplace on `main` fast-forwards safely. A dirty, non-main, or unrecognised local marketplace remains unchanged and reports that its plugin update is incomplete while it still refreshes the always-on instruction. If the Codex marketplace source is unknown, it stops without changes.
+9. Run only the selected host by default. Use `--host all` only when the user explicitly asks to install or update every detected host.
+10. Show the required reload step from the helper output. Do not claim the command is ready until the host reloads.
+
+## Supported Hosts
+
+- Claude Code: refresh the marketplace and plugin, then run `/reload-plugins`.
+- Codex: refresh a confirmed Git marketplace and apply the plugin, then start a new task or restart Codex. A clean official local `main` checkout fast-forwards and applies the plugin. Other local checkouts keep their work unchanged, refresh the always-on instruction, and report what needs attention. An unknown source stops the update to protect local work.
+- GitHub Copilot: refresh the marketplace and plugin, then restart the CLI session or start a new app chat.
+- Google Antigravity: install or reinstall the repository plugin with `agy`, then start a new Antigravity session.
+- Grok Build: install or update the repository plugin with `grok`, then start a new Grok Build session.
+- VS Code: install or update `EnterpriseAI.gofer`, then run **Developer: Reload Window**.
+
+## Limits
+
+- This command updates user-level plugins and extensions. It archives known stale Gofer entries and replaces only Gofer's managed instruction section. It does not remove unrelated user files or host-managed plugin caches. It does not add the repo-owned `.specify/` scaffold.
+- For a repository scaffold, use `/eai add or refresh the Gofer scaffold for this repo` after the host update.
+- Gemini files remain only for legacy file-format compatibility. Gemini is not a current updater host.
+- Keep the full Gofer delivery pipeline unchanged. This command only manages its host installation.
+
+**Blocker Mediation**
+
+- Before repeating a failed action or asking for missing input, read .specify/references/blocker-mediation.md and inspect the private blocker register with gofer-blocker-control.mjs. Reuse the same state directory and goal, subject and condition keys across stages, restarts and surfaces. Different wording, models or tools do not create a new blocker.
+- Classify the cause first. Missing user decisions, access, external dependencies and unavailable capabilities require a recorded wait. Reserve an ask event before asking; ask once, explain the business impact and required change, then stop affected work. An unanswered question is not new evidence. Do not poll or rephrase it to keep running.
+- Technical ask events require a fresh verification file under .specify/references/priority-outcome-protection.md: actual diagnosis, self-cause check and why no authorized repair is available. Business choices need no failed command. For feature tasks, use gofer-priority-check.mjs and the saved direction before switching work; this does not start delivery during maintenance or conversation.
+- For AI-solvable or unknown causes, reserve each attempt before execution. Allow one investigation and one different recovery within existing tighter budgets. Record its result even when interrupted or unsuccessful. An unfinished reservation must not launch again. Do not reset the register, change keys or switch surfaces to obtain more attempts.
+- Resume only after a real user answer or changed external evidence has been recorded and checked. The helper allows one evidence-backed resumption; exhausted limits need human review. Never invent approval or evidence. Successful model output and a running server do not resolve a blocker without the relevant check.
+- Save the blocker, unfinished tasks and next action before stopping. Continue only approved tasks that do not depend on it. Keep the original goal; update specs, plans, tasks and validation for accepted direction changes, and reopen stale checks. Do not quietly drop requirements to make progress.
+- Use node .specify/scripts/node/gofer-blocker-control.mjs --state-dir <private-state-directory> --event <private-event.json> before controlled actions; inspect with --state-dir alone, or add --task T001 for an independent task. A denied action, invalid record or missing helper means stop and explain the limitation, not bypass it. Use the installed plugin script path if no repo scaffold exists. Conversation-only work uses a private session state directory and does not require app setup or feature files.
+- Strict loop validation checks every recorded feature blocker. Shared instructions guide native chats; this helper cannot intercept calls that a host sends directly. Do not claim native enforcement from package tests alone.

package/resources/gofer/github-skills/gofer-documentation/SKILL.md

@@ -0,0 +1,93 @@
+---
+name: gofer-documentation
+description:
+  'Write or update customer-facing delivery documentation and generate its
+  PublicAPI-capped lineage diagram. Use for Markdown, requirements,
+  architecture, decisions, plans, validation evidence, or documentation graphs
+  in a Gofer workspace.'
+---
+
+# Gofer Documentation And Lineage
+
+Use this skill whenever an agent creates or changes delivery documentation in a
+Gofer workspace. The durable outputs are human-readable Markdown plus
+`.specify/specs/{feature}/delivery-lineage.json`.
+
+## Trust Boundary
+
+Gofer is customer-side. Read `.specify/references/delivery-lineage.md` before
+writing and enforce all of its export rules.
+
+- Use `plane: customer`.
+- Stop EAI dependencies at a `public-api-capability` node from `PublicAPI`.
+- Never name or link internal EAI services, repositories, policies,
+  infrastructure, `tech-docs`, or personal absolute paths.
+- Do not create an internal graph and rely on a viewer filter. The persisted
+  graph itself must be safe for the customer.
+- Record concise rationale and evidence, never hidden chain-of-thought.
+
+## Write The Markdown
+
+1. Preserve the repository's existing documentation conventions. For a new
+   durable document, use frontmatter with a stable `doc_id`, `title`, `status`,
+   `owners`, and `updated` date.
+2. Keep the stable `doc_id` when the title or path changes. Mark replaced
+   documents `superseded` and link their replacement.
+3. Use descriptive headings so graph sources can point to exact anchors.
+4. Separate requirements, decisions, considered options, concise rationale,
+   acceptance evidence, and outcomes. Do not present a plan as delivered fact.
+5. Use repository-relative links and paths. Include a Git commit and SHA-256
+   content hash in lineage sources when known.
+
+## Record The Selected Decision
+
+Use one explicit heading for each material outcome so the viewer can separate
+the accepted path from alternatives:
+
+- `## Selected Approach`, `## Approved Direction`, `## Chosen Option`, or
+  `## Architecture Decision` for an accepted choice;
+- `## Rejected Alternative` or `## Declined Option` for an option not taken;
+- `## Superseded Decision` when a later choice replaced it.
+
+State the decision itself in the first paragraph below the heading. Keep the
+concise rationale and consequences below it. The viewer records the heading as
+an anchored decision node, shows the latest current accepted decision as the
+**Final selected decision**, and highlights the current customer delivery path
+while fading rejected, superseded, or unhealthy evidence.
+
+## Update The Graph
+
+1. Resolve the active feature under `.specify/specs/`.
+2. Create `delivery-lineage.json` from
+   `.specify/templates/delivery-lineage-template.json` if it is missing.
+3. Preserve node and edge IDs. Add or update nodes for the changed documents,
+   requirements, decisions, work orders, code, tests, outcomes, and published
+   PublicAPI capabilities.
+4. Link evidence with the narrowest accurate relation. Mark stale or unresolved
+   sources `suspect`, `anchor-lost`, `broken`, or `superseded`; do not silently
+   drop them.
+5. Run the repository lineage tests before declaring the graph valid.
+
+## Generate Or Show The Diagram
+
+Run:
+
+```bash
+node .specify/scripts/node/render-delivery-lineage.mjs \
+  --input .specify/specs/{feature}/delivery-lineage.json
+```
+
+This writes `delivery-lineage.md` beside the manifest with a portable Mermaid
+graph. When the Gofer VS Code extension is active, run **Gofer: Show Delivery
+Lineage** (`gofer.showDeliveryLineage`) for the interactive graph. In a
+terminal-only host, show the Mermaid block in chat when supported and always
+return links to both generated files.
+
+## Completion Check
+
+- Markdown claims have exact source anchors.
+- The persisted graph contains no private EAI visibility.
+- All edges resolve to existing nodes.
+- The diagram was regenerated after the final graph change.
+- The final selected decision and selected delivery path are visible.
+- The summary names documentation changed and evidence still non-current.