Add provenance and repository grounding to ooo auto interview answers

[shaun0927]

Status (synced 2026-05-07)

Done

• Bounded fact-injection interface — AutoAnswerContext + repo_facts evidence labels (Ground auto runtime answers in supplied repo facts #646).
• Bounded repo-fact discovery for Python projects — repo_context.py + AutoInterviewDriver wiring (feat(auto): feed repo facts into interview answers #666).
• Explicit user-goal hydration through Seed gating — adjacent slice covering goal-fact preservation (Preserve explicit auto goal facts through Seed gating #652).
• Tests: repo-grounded answer, fallback answer, repo-fact-vs-blocker precedence (Ground auto runtime answers in supplied repo facts #646/feat(auto): feed repo facts into interview answers #666).

In review (this issue's remaining slices)

• Provenance surface on auto pipeline / MCP output — ledger summary now exposes provenance, evidence_backed_sections, assumption_only_sections; AutoPipelineResult and ouroboros_auto MCP response surface them. PR: feat(auto): expose ledger provenance in auto pipeline result #693.
• Risky-fallback gating — block regulated-data (PII/GDPR/HIPAA/SOX/PCI-DSS) and destructive bulk schema/table fallbacks instead of silently filling with a generic default. PR: feat(auto): block risky-fallback answers for regulated topics #695.

Tracked separately (do not address inside #640)

• Bounded repository grounding for non-Python projects → Expand bounded auto repository grounding beyond Python projects #676 (PR: feat(auto): expand bounded repo context #681).
• Selected-driver post-response risk/confidence tagging → Add post-response risk and confidence tagging for selected-driver auto answers #675 (PRs: feat(auto): add selected-driver answer metadata #682, feat(auto): classify selected-driver answer risk #683).
• Umbrella autopilot follow-up tracker → Track ooo auto autopilot follow-up implementation slices #678.

Closing criteria

Once #693 and #695 merge, this issue can close — the remaining repo-grounding and selected-driver work is owned by the trackers above.

---

Problem

The current ooo auto interview answerer is conservative and deterministic, but it is not sufficiently repository-aware. It answers interview questions from generic heuristics rather than grounded facts about the current codebase unless external facts are explicitly provided by another layer.

That makes it hard for users to trust that ooo auto selected the right implementation constraints for brownfield or repository-specific tasks.

Evidence

AutoAnswerer is intentionally bounded and heuristic-driven. It handles broad question classes such as:

• non-goals
• verification
• acceptance criteria
• actor / input / output
• runtime
• default conservative answers

This is safe, but it means ooo auto can produce plausible answers without proving that the answers match the active repository.

User impact

For tasks like validating GitHub issues/PRs, checking existing implementation behavior, or modifying an established project, users need to know whether auto-selected answers came from:

• direct repository inspection
• existing project memory
• user-provided constraints
• generic fallback assumptions

Without that distinction, the resulting Seed may look authoritative while being based on defaults.

Proposed fix

Introduce explicit evidence provenance for auto interview answers:

• distinguish repo_fact, user_constraint, memory, policy_default, and fallback_assumption
• include citations/file references when an answer is based on repo inspection
• optionally add a bounded repository discovery pass before answering brownfield questions
• block or ask the user when a required answer would otherwise be a risky fallback

Acceptance criteria

• Auto interview answers include machine-readable provenance.
• The final Seed or ledger shows which constraints are evidence-backed versus assumed.
• Brownfield tasks trigger a bounded repository-context collection step or explicitly report that no repo facts were used.
• Tests cover at least one repo-grounded answer and one fallback assumption answer.

---

Scope clarification

The code already defines provenance-like answer sources, including:

• USER_GOAL
• REPO_FACT
• EXISTING_CONVENTION
• CONSERVATIVE_DEFAULT
• ASSUMPTION
• NON_GOAL
• BLOCKER

The missing piece is not merely adding an enum. The missing piece is a bounded context/fact input path that lets AutoAnswerer use repository facts when they are explicitly supplied.

Narrowed first PR scope

The first PR should add an explicit context/fact injection interface without implementing broad repository crawling.

Suggested shape:

• introduce an optional AutoAnswerContext or RepoFactProvider input
• allow AutoAnswerer to use supplied repo facts for runtime/framework/project-structure questions
• preserve current conservative fallback behavior when no facts are supplied
• record whether an answer came from a repo fact or from a fallback assumption/default

First PR tests

Add tests for:

1. repo fact supplied → answer uses repo_fact / existing_convention provenance
2. no repo fact supplied → answer remains conservative default or assumption
3. risky/unsafe questions still block rather than using a weak repo fact

Explicitly out of scope for the first PR

• full repository scanning/crawling
• network access
• large project indexing
• changing Seed review/repair gates
• changing MCP dispatch behavior

A bounded repository discovery pass can be designed as a follow-up once the answer context interface exists.

[ouroboros-agent]

This looks like a multi-PR effort that needs design discussion before implementation. Labeling needs-design for human planning.

Scope assessment:

• src/ouroboros/bigbang/interview.py already handles brownfield detection and repository exploration, but does not preserve per-answer provenance or risky-fallback gating.
• src/ouroboros/core/seed.py, src/ouroboros/bigbang/seed_generator.py, and src/ouroboros/mcp/tools/definitions.py would need schema and output changes so provenance is machine-readable and visible in generated Seed/ledger surfaces.
• Tests would need coordinated updates across interview, seed generation, and MCP/CLI integration, which points to a cross-cutting design change rather than a single isolated fix.

Estimated complexity:
High. This likely needs a provenance data model, rules for when fallback answers are allowed, and a decision on where evidence should appear in persisted interview/Seed artifacts.

Suggested approach:

1. Define the provenance taxonomy and required storage location first.
2. Decide whether provenance lives in interview rounds, seed metadata, or a separate ledger artifact.
3. Split implementation into follow-up PRs for answer generation, seed/reporting surfaces, and test coverage.

ouroboros-agent[bot]

[shaun0927]

Concrete failing case from a live ooo auto ... --skip-run run:

The initial goal explicitly included:

• actor: local developer or automated agent
• inputs: no CLI args / no stdin
• outputs: exact hello\n, no stderr, exit 0
• runtime context: local Unix-like shell in a temp scratch dir outside real projects
• non-goals, acceptance criteria, verification plan

Even so, the auto ledger ended with empty required sections for actors, inputs, outputs, and runtime_context, and the session blocked with:

interview backend completed before auto ledger was ready: actors, inputs, outputs, runtime_context

This shows the missing grounding path is not only repo facts; it also includes explicit user-goal facts. A narrow first fix is to hydrate ledger sections from clearly labeled goal facts before the interview readiness gate runs.

PR implementing that narrow user-goal hydration slice: #652