FAI What Context Needed

Goal

Identify exactly what information is required before implementation to avoid low-quality or hallucinated output.

Context Dimensions

Step 1 - Extract Task Type

Classify the request as one of:

• Feature implementation
• Refactor
• Bug fix
• Migration
• Documentation/test generation

Step 2 - Build Context Checklist

{
  "required": [
    "entry files",
    "calling interfaces",
    "config and environment assumptions",
    "tests or evaluation criteria"
  ],
  "optional": [
    "architecture docs",
    "performance baselines",
    "release constraints"
  ]
}

Step 3 - Rank by Impact

Step 4 - Define Sufficiency Gate

Context is sufficient when:

1. Affected files are known.
2. Expected behavior is explicit.
3. Validation method is available.
4. Security and cost constraints are identified.

Step 5 - Output Structured Context Request

Need before implementation:
1) Entry point file(s)
2) Current contract/schema
3) Constraints (runtime, policy, latency)
4) Acceptance test cases

Troubleshooting

Advanced Implementation Notes

Operational Guardrails

• Define measurable SLOs before rollout.
• Capture baseline metrics and compare deltas post-change.
• Add alert thresholds with explicit on-call ownership.
• Use environment-specific overrides for dev/staging/prod.

CI/CD and Validation Expansion

# Example verification sequence
npm run lint
npm test
npm run build

{
  "quality_gate": {
    "required": true,
    "min_score": 0.8,
    "block_on_failure": true
  }
}

Security and Compliance Checks

Performance and Cost Notes

• Budget requests and tokens per endpoint/class of workload.
• Profile p95 and p99 latency as separate objectives.
• Add caching only where correctness is preserved.
• Use periodic reports to catch drift in cost/quality.

Extended Troubleshooting