feat(aidd-dev/plan): validate feature runtime prerequisites before implementation #955

Problem

aidd-dev:01-plan already has an explore phase for feasibility, project Rules, risks, architecture projection, and implementation planning. Its current feasibility contract is nevertheless too unconstrained for features that depend on runtime infrastructure.

This is a strengthening of an existing 01-plan/explore responsibility, not an unrelated new concern. PR #271 introduced the current gather → explore → wireframe → plan structure and explicitly made explore responsible for projection, Rules, feasibility, and risks. It made feasibility a first-class responsibility, but did not define a structured runtime-prerequisite validation contract. Feasibility is therefore still too unconstrained for operational dependencies.

plugins/aidd-dev/skills/01-plan/actions/02-explore.md asks the agent to list infrastructure assumptions and verify feasibility against documentation or in-repository code, recording the consulted source and what it settled. It does not require the agent to correlate a configured provider, endpoint, model, service, or other runtime prerequisite with the target environment's actual deployed state and produce a blocking/non-blocking verdict. 04-plan then consumes that explore output as the basis for the implementation plan.

This can produce a plan that is logically coherent but operationally non-executable even when the relevant evidence already exists. A concrete case was observed while planning OpenViking activation for Hermes: the intended configuration used defaults such as OPENVIKING_EMBEDDING_PROVIDER=ollama and OPENVIKING_EMBEDDING_API_BASE=http://ollama:11434/v1, while Ollama was not present in the Hermes Compose deployment and project/deployment context indicated that it was stopped or unavailable. The plan identified abstract embedding-model and VLM needs, but did not connect the configured provider and endpoint to the deployed services.

The gap is therefore not simply missing information. 01-plan/explore does not currently force the chain:

configuration
    ↓
runtime dependency
    ↓
target environment
    ↓
actual availability
    ↓
blocking/non-blocking verdict

This is the feature-level gap left between the adjacent concerns: #954 proposes repository-wide development/workflow readiness, while this issue makes runtime feasibility explicit for the specific feature being planned. #271 established the feasibility seam; this issue tightens its operational depth.

Scope

• Strengthen the existing aidd-dev:01-plan exploration contract, using the 02-explore feasibility seam, so that it conditionally assesses runtime and operational prerequisites when the proposed feature introduces or relies on them.
• For each relevant prerequisite, record an architecture-consistent mapping from configuration or feature requirement to dependency, expected service/location, actual state, evidence, and classification. A literal table is not required if the existing planning artifacts provide a better representation.
• Cover applicable dependencies such as services, databases, APIs, model/LLM/VLM/embedding providers, containers, commands or binaries, volumes, secrets, permissions, filesystem paths, ports/network connectivity, image versions, migrations or initialization, and backup/restore prerequisites when relevant.
• Require evidence from the target environment or its authoritative deployment/configuration state before classifying a prerequisite as validated. Documentation or a default configuration alone must not count as proof of availability.
• Make the resulting verdict explicit before the plan is presented as executable, distinguishing validated prerequisites from missing/blocking, unverified, and non-blocking-risk conditions. Terminology may follow existing AIDD conventions.
• Keep the assessment proportional: simple changes with no introduced or relied-upon runtime dependency follow the existing flow without an infrastructure audit.

Acceptance criteria

• 01-plan conditionally triggers runtime-prerequisite assessment when the feature introduces or relies on runtime/operational dependencies, and does not require it for dependency-free code changes.
• The planning output maps each relevant prerequisite to its configuration or requirement, dependency, expected target service/location, actual state, evidence, and classification or equivalent architecture-consistent fields.
• A prerequisite is not classified as validated solely because documentation, a default value, or a planned configuration references it; validation cites evidence from the target environment or authoritative deployment state.
• The output explicitly distinguishes validated, missing/blocking, unverified, and non-blocking-risk conditions, using established terminology if the repository has a better equivalent.
• A missing or unavailable prerequisite prevents the plan from being presented as executable, or is explicitly carried as a blocking condition requiring resolution before implementation; an unverified prerequisite is not silently treated as available.
• The plan preserves the existing feasibility source/evidence and risk reporting, and carries the prerequisite verdict into the existing planning artifact without creating a competing source of truth.
• A representative fixture or example covers a configured provider/endpoint whose service is absent from the target Compose/deployment state and produces a blocking result, while an available declared volume or equivalent prerequisite can be validated with evidence.
• The normal planning flow remains unchanged for features with no relevant runtime prerequisites.

Prior art in this repo

• PR #271 — refactor(aidd-dev): redesign 01-plan into gather/explore/wireframe/plan introduced the current four-action structure and explicitly assigned projection, Rules, feasibility, and risks to 02-explore. It established feasibility as an 01-plan/explore responsibility, but did not define a structured contract for correlating feature runtime prerequisites with actual target-environment availability. This issue strengthens that existing seam rather than introducing a separate concern.
• #275 — feat: persist brainstorm decisions and have plan ingest them is secondary conceptual prior art: it established that information being available is not sufficient unless the workflow explicitly wires it into the downstream step that depends on it. It does not solve runtime-prerequisite validation; the relevant precedent is its explicit information handoff/correlation principle.
• plugins/aidd-dev/skills/01-plan/SKILL.md#L11-L21 defines the gather → explore → wireframe → plan flow and assigns feasibility reading to explore.
• plugins/aidd-dev/skills/01-plan/actions/02-explore.md#L9-L23 already outputs feasibility checks and risks, asks the agent to list infrastructure assumptions, and requires each feasibility check to record a source and what it settled; it does not require runtime-state correlation or an availability verdict.
• plugins/aidd-dev/skills/01-plan/actions/04-plan.md#L5-L19 consumes the explore output to write and review the implementation plan, making it the handoff boundary where an unresolved blocker must remain visible.
• plugins/aidd-dev/skills/01-plan/assets/plan-template.md provides the existing plan artifact and should remain the source of truth for any persisted assessment rather than introducing a parallel prerequisite store.
• #896 establishes a conditional planning-time risk assessment for regression safety; this issue is complementary and covers runtime executability rather than regression coverage.
• #928 derives contributor validation commands from authoritative repository workflows; this issue is complementary and covers feature prerequisites required to operate the planned runtime, not contributor-command selection.
• #954 proposes repository-wide development/workflow readiness; this issue is narrower and feature-scoped, making runtime feasibility explicit during planning for the specific proposed change.

Out of scope

• Performing a repository-wide or generic coding-agent readiness audit; see feat(aidd-dev): assess coding-agent development workflow readiness #954.
• Replacing the contributor-workflow validation contract or selecting arbitrary contributor commands; see feat(aidd-dev): derive validation from repository contributor workflows #928.
• Adding an infrastructure audit for every plan or requiring runtime checks for dependency-free changes.
• Inventing undocumented services, commands, endpoints, credentials, recovery procedures, or environment state.
• Treating documentation, configuration defaults, or a logical dependency as proof that the dependency is deployed and reachable.
• Automatically starting services, installing dependencies, provisioning infrastructure, changing deployment configuration, or mutating external environments during planning.
• Defining a universal infrastructure schema or requiring the literal example table when an existing AIDD planning artifact can represent the same evidence and verdict.
• Creating code or a pull request as part of this issue.