9_gofer_tests

---

description: Define acceptance test cases using DSL approach before or during implementation

Gofer Tests

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.

Application Classification And EAI Preflight

Before any EAI CLI, login, tenant, template, or app-enrollment action:

1. Classify the request as EAI app delivery or non-application work using the application signals in .specify/commands/0_gofer_start.md.
2. Create .specify/specs/{feature}/ and record the active delivery scope before app or operator-tool source work.
3. If the request is clearly non-app work, confirm once: "This looks like non-app work, so I will skip EAI tenant/app setup and continue the Gofer research/docs path. Is that right?"
4. If the user confirms non-app, record the decision and mark app-only capabilities not_applicable. Do not run eai whoami, eai tenant select, eai init, or /gofer:eai-first-run.
5. For local MVP app work, validate the implemented user journey, repo runner, and preview evidence. Do not require EAI setup, authentication, or deployment when the active specification does not require them.
6. When the feature uses EAI Platform services, requires a tenant, or prepares deployment, run eai whoami and record the EAI readiness evidence in eai-preflight.md.
7. When the feature creates, changes, or validates an EAI Platform app integration, run node .specify/scripts/node/eai-app-template-readiness.mjs --root . --json. A missing checker or status other than ready blocks that EAI capability. It does not block unrelated local MVP work.
8. When authentication is implemented or required, validate provider, callback, sign-in, session, first protected API call, and safe denied access.
9. When deployment is requested or claimed, require the relevant EAI template, security, configuration, and deployment evidence before completion.
10. For durable app delivery, use EAI Platform first, Azure second, and every other stack only by explicit exception.
11. If the user changes scope, update spec.md, plan.md, tasks.md, traceability.md, and validation scope before continuing. Explain the business effect and evidence change.
12. Do not accept copied marker files, partial scaffolds, or custom templates as readiness evidence for an EAI capability.
13. Do not write tokens, secrets, private tenant IDs, or local .env values into Gofer artifacts; record only product-safe readiness status and evidence.