feat(aidd-dev): derive validation from repository contributor workflows #928

Objective / Problem

AIDD executes validation commands that are present in the plan, but the planning and delivery flow does not explicitly derive those commands from the repository's authoritative contributor workflow.

As a result, an implementation can pass AIDD's technical assertions and tests while still failing a command that maintainers expect contributors to run before submitting a pull request.

A concrete example was exposed during the framework's local reload workflow: make reload exercised repository-specific generation and installation behavior that was not covered by the validation performed during implementation. The public incident is represented by PR #904, where the reload script still used the obsolete framework build behavior after the framework had moved to translate.

The gap is broader than tests. Contributor workflows may include generation, reload, formatting, linting, packaging, compatibility checks, build steps, or repository-specific sanity checks.

Outcome

During planning, AIDD identifies authoritative contributor validation workflows from the repository, determines which checks apply to the requested change, records them in the plan, and carries that validation contract through implementation and review.

Feature completion must reflect the repository's documented contribution contract, not only inferred technical checks.

Proposed Solution

• Extend aidd-dev:01-plan exploration to inspect authoritative contributor workflow sources.
• Recognize explicit contribution and validation contexts in sources such as CONTRIBUTING.md, relevant README.md sections, Makefiles, package scripts, pyproject.toml, Taskfiles, Justfiles, developer documentation, and explicitly referenced local pre-PR checks.
• Add a structured validation contract to the plan or another existing planning artifact.
• Classify discovered commands as mandatory for all contributions, applicable to the changed area, optional/informational, or ambiguous/requiring human decision.
• Carry applicable commands from 01-plan through 02-implement finalization.
• Preserve 03-assert as the owner of coding assertions and conformance checks.
• Preserve 06-test as the owner of project-owned automated tests, including the boundary established by #907.
• Make 05-review verify that the declared validation contract was addressed and that evidence exists.
• Make the SDLC Check stage consume the resulting validation evidence without attempting to reproduce an arbitrary CI matrix.
• Keep Rules and Project Memory as complementary sources for constraints not already expressed by the repository, or for explicit disambiguation.

Source and trust model

A command must not be selected merely because it appears in documentation.

A candidate command is eligible only when it appears in an explicitly contribution-related context, for example:

• Before submitting a PR;
• Development checks;
• Validation;
• Testing;
• Contributing workflow.

When multiple sources disagree, AIDD must expose the conflict in the plan or request a decision. It must not silently choose a command.

Commands must not be executed automatically when they are destructive, publish externally, require secrets, mutate unrelated repositories or environments, or have an unbounded/costly runtime. Such commands should be reported as requiring explicit authorization.

Before executing a target such as make reload, AIDD should inspect the target definition sufficiently to identify its side effects.

Relationship with Rules and Project Memory

This issue does not replace Rules or Project Memory.

Framework-level responsibility:

• discover that the repository has an authoritative contribution workflow;
• extract the applicable validation contract;
• carry it through planning, implementation and review.

Project-specific responsibility:

• define constraints absent from repository documentation;
• add internal security or operational requirements;
• resolve ambiguity or priority when repository sources conflict.

A user should not have to duplicate CONTRIBUTING.md merely to restate commands that are already the repository's source of truth, such as:

Before submitting a PR:
  make reload
  make test

Acceptance criteria

• 01-plan explicitly searches authoritative contributor and validation sources.
• The plan records whether each discovered command is mandatory, scope-specific, optional, or unresolved.
• Commands are selected only when supported by contribution-related context or an explicit declarative project contract.
• 02-implement executes applicable recorded commands during final validation.
• Validation evidence includes command, source, applicability decision, exit status and relevant output.
• 05-review reports a missing or unverified mandatory command as a functional finding.
• 03-assert remains responsible for coding assertions and does not absorb repository-workflow discovery.
• 06-test remains responsible for automated testing and does not become the owner of reload, generation, packaging or arbitrary contributor workflows.
• The SDLC Check stage can consume contributor-workflow validation evidence without reproducing arbitrary CI.
• Conflicting sources are surfaced rather than resolved silently.
• Destructive, external, secret-dependent or unbounded commands require explicit authorization or are reported as not automatically runnable.
• A fixture covers a repository whose CONTRIBUTING.md requires a non-test command such as make reload.
• A fixture proves that an unrelated command appearing in ordinary documentation is not executed.
• The normal flow remains unchanged when no authoritative contributor workflow is found.
• Rules and Project Memory remain valid for additional constraints and disambiguation.

Out of scope

• Reproducing an arbitrary CI matrix.
• Executing every command found in repository documentation.
• Replacing Project Memory or Rules.
• Creating a new validation or testing skill unless the existing plan, implement, assert and review contracts prove insufficient.
• Installing dependencies or changing project configuration without explicit authority.
• Defining universal command precedence for every possible repository format.

Related work

• #907 — reserves aidd-dev:06-test for automated technical tests.
• #919 — adds independent Acceptance QA before draft pull requests.
• #927 — carries documentation impact through feature delivery.
• #887 — clarifies the SDLC Check exit and review loop.
• PR #904 — concrete make reload / translate incident.