Enter the access password to view the site.
Operational reference for ensuring teams use the right models for the right jobs, maintain context hygiene, write efficient prompts, and use tools appropriately — covering everything from model routing through cost governance. Phase / gate vocabulary follows the FDLC canvas (Phase 0–4, G0–G4). For per-activity guidance on what AI does at each phase, see the Activity matrix addendum; this document covers how to operate those activities efficiently.
Wrong model for the task (cost multiplier problem), over-loaded or stale context (quality degradation that triggers correction cycles), and under-specified prompts (verbose outputs that aren't usable). Fix these three and you address ~85% of cost inefficiency. Everything else is optimization at the margin.
Three model tiers serve fundamentally different task classes. The decision is not "what's the best model" but "what's the minimum sufficient model." A rule-based compliance check run on Opus costs ~15–20× more than the same check on Haiku with identical output quality. Over a rollout of 50+ features per quarter, this compounds to significant unnecessary spend. The agents named in each tier below correspond to activities in the Activity matrix addendum — cross-reference there for ownership, phase/gate placement, and starter prompts.
Use when the correct output is deterministic from the inputs — no synthesis, no creative judgment, no multi-step reasoning required. If you can write a rule for what the output should be, Haiku can produce it. Fast turnaround makes it suitable for pre-gate blocking checks where latency matters.
| Agent | Est. tokens (in / out) | Rationale |
|---|---|---|
| Spec completeness / P7 sufficiency | 3k–6k / 400–600 | Deterministic rule checking against known schema |
| Decision log integrity | 2k–4k / 200–400 | Pattern matching across structured logs |
| DS compliance validation | 2k–5k / 300–500 | Rule-based token/component list check |
| AC quality check | 2k–4k / 300–500 | Three binary rules: testable? independent? state-mapped? |
| Dependency / contract screening | 3k–8k / 400–600 | LDG lookup + entity pattern matching |
| Localization pre-screen | 2k–5k / 200–400 | Pattern detection against locale config rules |
| Cycle time telemetry capture | 2k–3k / 150–300 | Structured data extraction from git/ADO logs |
| Gate checklist pre-population | 2k–5k / 300–500 | Templated fill from spec — no judgment required |
| PR description | 3k–5k / 400–700 | Structured template fill from unit brief + review log |
| Rollout configuration | 2k–4k / 300–500 | Structured mapping from engineering spec |
| Contract change notification | 2k–4k / 200–400 | LDG lookup + templated notification generation |
| Analytics plan validation | 3k–6k / 300–500 | Pattern matching against infra inventory |
Use when the task requires reading across multiple sources and producing integrated output, or when the output is generative (code, documentation, design variants) within a defined constraint space. Sonnet handles the majority of substantive FDLC agent work. If an agent is doing synthesis or generation with clear inputs, Sonnet is the default — not Opus.
| Agent | Est. tokens (in / out) | Rationale |
|---|---|---|
| Research synthesis | 10k–40k / 2k–4k | Complex synthesis but bounded task; Opus not warranted |
| Design generation (Spec-First) | 15k–30k / 3k–8k | Constrained generation within known DS + spec |
| Engineering spec draft | 8k–15k / 3k–6k | Structured generation from G3-approved inputs |
| Engineering build (per unit) | 10k–20k / 2k–6k | Code generation from spec within constitution |
| G3 review brief | 8k–15k / 1k–2k | Feature folder synthesis; no novel judgment needed |
| Output generation suite | 8k–12k / 4k–8k | Multiple structured documents from single spec input |
| Spec-to-prototype reconciliation | 10k–20k / 1k–2k | Code + spec diff analysis; structured output |
| Friction signal synthesis | 10k–25k / 1k–3k | Qualitative synthesis across signal channels |
| VoC synthesis (call recordings) | 20k–60k / 2k–4k | High-volume transcript processing; clear task |
| Copy / content generation | 5k–10k / 1k–2k | Creative within brand + DS constraints |
| Enhancement candidate generation | 6k–10k / 1k–2k | Structured brief authoring from signal |
| JTBD completion rate analysis | 5k–10k / 500–1k | Data analysis + trend interpretation |
Reserved for tasks where the quality of reasoning materially affects a high-stakes outcome, where the constraint space is genuinely novel, or where the task requires simultaneous consideration of many competing factors that Sonnet demonstrably handles worse. Opus should never be a default — its use must be deliberate and logged.
| Agent | Est. tokens (in / out) | Why Opus justified |
|---|---|---|
| Design generation — New Paradigm only | 20k–40k / 5k–15k | Constraint space is genuinely novel; creativity ceiling matters |
| Cross-domain spec alignment | 15k–30k / 2k–4k | Multi-spec simultaneous reasoning; architectural judgment |
| LLM-as-judge (Tier B–C rubric) | 10k–20k / 1k–3k | Judgment-intensive rubric; scoring quality has gate consequences |
| Architecture decision record drafting | 10k–20k / 2k–5k | High-stakes; consequential; nuanced tradeoff reasoning |
| Opportunity sizing (strategic) | 8k–15k / 1k–2k | Strategic judgment + market reasoning; CPO-facing |
The FDLC has well-defined context loading. The optimization problem is that teams default to loading everything relevant rather than the minimum required. Context over-loading degrades output quality (attention dilution on irrelevant content) and increases cost simultaneously — the worst possible tradeoff.
Core rules, patterns, and constraints that apply across all features and all domains.
Domain-specific patterns, component coverage, heuristics, and design constraints for this domain.
The G2-locked spec.md and active decision log for this specific feature. Changes at gate transitions and on amendments.
Current unit of work brief, recent generation/review cycles (last 2–3 iterations). Not the full session history.
| Agent category | L0 (Foundation) | L1 (Domain) | L2 (Feature spec) | L3 (Session) |
|---|---|---|---|---|
| Rule-based checks (Haiku) | Rarely — only if rule is in L0 | No | Yes — section-selective | No |
| Design generation (Sonnet/Opus) | Yes — cached | Yes — cached | Yes — full spec | Yes — sliding window |
| Engineering build (Sonnet) | Yes — cached | Engineering sections only | Yes — §2.3, 2.4, 2.5 | Yes — current unit brief |
| Validation agents (Haiku) | DS rules only — not full constitution | Component coverage section only | Yes — §2.4 state list | No |
| Synthesis / research agents (Sonnet) | No | No | Signal brief + G1 problem statement | No |
| Post-ship analysis (Sonnet) | No | No | Job statement + analytics plan only | No |
Anthropic's prompt caching reduces input token cost by ~90% for cached content. The constitution and companion files are ideal candidates — large, stable, and accessed in nearly every substantive agent session. Caching is the single highest-ROI context optimization available.
| Document | Avg size | Cache rate | Cost saving |
|---|---|---|---|
| Platform Constitution Used in every generation, validation, and build session | 12k–20k | 95%+ | ~90% of input cost for this block |
| Domain Companion File Domain-stable between pattern promotions | 5k–15k | 85–95% | ~90% within-sprint |
| Design Constitution Changes less frequently than companion files | 8k–12k | 90%+ | ~90% of input cost for this block |
| Feature Spec (spec.md) — gate-locked Stable between gate transitions; amendments invalidate | 3k–10k | 60–80% | ~90% between amendments |
| Spec template structure Section headers and schema — never changes | 1k–2k | 100% | Small but consistent |
| Decision log Appended continuously; partial caching of historical entries | 1k–6k | 50–70% | Partial — new entries not cacheable |
Most agents need specific sections of the spec, not the full document. Loading only the relevant sections reduces input tokens and reduces attention dilution — the model focuses on what matters.
| Agent / task | Load these spec sections | Skip these sections |
|---|---|---|
| DS compliance validation | §2.4 (state list), §1.8 (constraints) | §2.3 (data shape), §2.5 (service hooks), §1.1–1.5 (problem framing) |
| Engineering build sessions | §2.3 (data shape), §2.4 (state list), §2.5 (service hooks), §1.6 (AC list) | §1.1–1.4 (problem framing), §1.8 design constraints |
| Spec-to-prototype reconciliation | §2.3, §2.4, §2.5 only | Everything else — reconciliation is structural, not semantic |
| JTBD completion rate analysis | §1.2 (job statement), §5.x (analytics plan) | All implementation sections |
| AC quality check | §1.6 (AC list), §2.4 (state list) | All other sections |
| Constraint inventory generation | §1.8 (constraints), §2.4 (state list) + L0 + L1 | Problem framing, ACs, data shape |
Generation sessions that run multiple units of work can accumulate full session history in context. This is the most common cause of exponential cost growth within a session. Use a sliding window: retain the last 2–3 generation/review cycles in active context; archive earlier rounds as a compressed summary.
A correction cycle costs 2–4× what a single-shot well-prompted output costs. Prompt quality investment pays off immediately. The following are the highest-leverage prompt practices for the FDLC's agent pattern — not general best practices, but specific guidance for the task types in the workflow.
Unconstrained output is the primary prompt-level source of token waste. Models generate to fill space. Every agent prompt must specify output format, length ceiling, and structure. For agents feeding other agents, the format must be what the downstream agent can parse without transformation.
| Task type | Use CoT? | Rationale | Alternative |
|---|---|---|---|
| Classification / rule check | No | Output is a category, not a reasoning chain. CoT adds 3–10× tokens for no quality gain. | Direct output with confidence score if needed |
| Structured data extraction | No | Extraction is mechanical. CoT reasoning doesn't improve accuracy on well-defined schemas. | Schema + examples are sufficient |
| Template filling | No | The template is the reasoning structure. CoT is redundant. | Template as the prompt structure |
| Design generation (Spec-First) | Optional | Rationale for constraint decisions is useful. Limit to 2–3 sentences per decision, not a full reasoning chain. | Decision log format: decision → why → spec section |
| Architecture decision record | Yes | The reasoning IS the output. The ADR is a reasoning artifact. CoT produces the content. | N/A — reasoning required |
| LLM-as-judge evaluation | Yes | Rubric scoring requires explicit reasoning to be auditable and contestable. | N/A — reasoning required for auditability |
| Cross-domain spec alignment | Yes | Multi-spec comparison needs explicit reasoning to produce actionable conflict descriptions. | N/A — reasoning produces the finding detail |
Ad-hoc prompts are the largest single source of correction-cycle waste. Every agent type must have a tested, standardized prompt template stored in the FDLC repo — not written from scratch per session. The starter prompts in the Activity matrix addendum are seeds for these templates; the design-prompt templates in that addendum already follow the six-section structure below. The template spec:
Each tool call has latency, cost, and the risk of returning more data than needed. The discipline is: plan tool calls before making them, batch where possible, request only what you need, and cache results within a session. A tool call waterfall — each call triggering the next based on the prior result — is the most expensive and slowest pattern possible.
These are the specific patterns that produce outsized cost waste in AI-enhanced product workflows. Most teams discover them the hard way. Each one has a structural fix — not a cultural ask.
During the pilot, token spend is logged at each gate but not constrained by hard limits — the goal is to establish an accurate cost baseline per tier. Post-pilot, per-feature token budgets are set based on pilot actuals + feature tier, governed through the AI FDLC Review. These budgets are alert thresholds that trigger trio review before the next phase begins, not hard stops. Cost visibility in real time is the goal; constrained data would undermine the baseline.
Side-by-side estimates for a complete feature (G0 through post-ship). Track B figures assume Sonnet-primary routing with prompt caching active on stable context layers. Track A figures are based on GPT-4o primary routing. Prompt caching is available in VS Code Copilot (VS Code 1.118+) and is now a real cost lever on Track A — see the A2 section for caching guidance. Estimates below reflect a pre-caching baseline; actual Track A costs may be lower depending on session discipline and VS Code version. The gap narrows further with SpecKit.
| Feature tier | Track B (with caching) | Track A (baseline est.) | Delta |
|---|---|---|---|
| Enhancement | $0.62–$1.35 | $0.85–$2.60 | +37–93% |
| New Capability | $1.30–$2.76 | $1.95–$5.85 | +50–112% |
| New Paradigm | $2.36–$5.34 | $3.40–$10.60 | +44–99% |
| Feature tier | G0→G2 | Design (G2→G3) | Engineering (G3→G4) | Post-ship | Full feature $ | Alert at |
|---|---|---|---|---|---|---|
| Enhancement | 20k–40k | 30k–60k | 40k–80k | 10k–20k | $0.62–$1.35 | 75% used |
| New Capability | 40k–80k | 80k–150k | 100k–200k | 20k–40k | $1.30–$2.76 | 75% used |
| New Paradigm | 60k–120k | 150k–300k | 150k–350k | 30k–60k | $2.36–$5.34 | 75% used |
The existing AI cost log (token spend by phase, by role, by track) is the right foundation. The monitoring system builds on top of it: anomaly detection, efficiency ratios, and phase benchmarks that make cost signal actionable rather than archival.
| Anomaly pattern | Threshold | What it signals | Investigation path |
|---|---|---|---|
| Single agent session cost spike | 3× median for that agent type | Context accumulation, model escalation, or correction cycle loop | Review session log: model used, context size at session open, number of correction cycles |
| Validation agent costs more than generation agent | Validation > 50% of generation cost for same feature | Validation agent over-loaded with context it doesn't need, or running on wrong model tier | Review validation prompt: is it loading full constitution? Is it running on Sonnet/Opus? |
| G2→G3 phase cost exceeds budget p90 | >p90 for feature tier | Correction cycles from spec gaps, generation stops, or variant count scope creep | Count generation attempts per variant; check spec gap log for gap count during generation |
| G3→G4 phase cost exceeds G2→G3 | Eng build > 2× design phase cost | Spec quality gap — engineering resolving ambiguity that should have been resolved at G2 | Review spec gap log volume; count post-G3 clarification overhead hours |
| Correction cycle rate > 2 per unit | Avg correction cycles/unit > 2 | Prompt quality problem or spec insufficiency; unit brief not specific enough | Review unit of work brief quality; check if spec sections cited in brief are complete |
| Tool call count exceeds budget | See Section 04 budgets by tier | Scope creep in session, redundant fetches, or waterfall tool call pattern | Review tool call log: identify redundant calls; check if session scope stayed within unit brief |
Raw token spend is a denominator without context. These ratios make spend meaningful — they're the signals that distinguish "we're spending more because we're building more" from "we have a workflow efficiency problem."
| Ratio | Formula | Healthy ratio | Degraded ratio signals |
|---|---|---|---|
| Cost per AC implemented | Total design phase spend ÷ ACs passing at G3 | Stable or decreasing as maturity improves | Increasing → correction cycle rate rising; spec quality declining |
| Cost per variant delivered | G2→G3 generation spend ÷ variants delivered at G3 | Consistent with variant count target for feature type | Rising → generation stop rate increasing; context quality declining |
| Useful output ratio | Output tokens in used artifacts ÷ total output tokens generated | >70% — most generated output is in the deliverable | <50% → verbose generation, correction cycles discarding output, over-generation |
| Check-to-gate cost ratio | Rule-based check spend ÷ total pre-gate spend | <15% — checks are cheap relative to synthesis and generation | >30% → checks running on wrong model; context over-loading on checks |
| Post-G3 clarification cost | G3→G4 spend attributable to clarification vs. generation | Trending toward zero as spec maturity improves | Stable or rising → spec quality not improving; handoff gap persisting |
The new model aligns Track A cost behavior much more closely with Track B than the old PRU system did. The base guide's core optimization principles — minimum sufficient model, context hygiene, output format discipline — now apply directly to Track A with direct dollar consequences rather than budget proxy consequences. The remaining differences are tooling architecture (no MCP, no CLAUDE.md, no persistent context) — not billing structure.
| Plan | Monthly seat price | Included AI Credits | Notes |
|---|---|---|---|
| Copilot Business | $19/user/mo | $19 / 1,900 credits | Pooled across org. Promo: $30 credits/user Jun–Aug 2026 |
| Copilot Enterprise | $39/user/mo | $39 / 3,900 credits | Pooled across org. Promo: $70 credits/user Jun–Aug 2026. Admin budget controls at enterprise/cost center/user level |
With usage-based billing, the base guide's token metrics now apply more directly to Track A. The VS Code Copilot usage panel and GitHub Billing Overview provide credit consumption visibility per interaction. The primary remaining translation need is from Anthropic token pricing to GitHub AI Credit pricing — the optimization logic is identical.
| Base guide metric | Track A equivalent | Where to find it |
|---|---|---|
| Token spend by phase | AI Credits consumed by phase (log at each gate) | GitHub Billing Overview + VS Code Copilot usage panel |
| Cost anomaly (3× median) | Credit spend 3× median for that session type | Billing Overview; flag in decision log same as Track B |
| Useful output ratio | Credits spent on sessions producing committed output ÷ total credits | Estimated from session log + commit history |
| Check-to-gate cost ratio | Credits on pre-gate check sessions ÷ total phase credits | Log check sessions separately in cost log |
| Model routing compliance | % sessions using minimum-sufficient model tier | VS Code model selection history; override log in decision log |
Full-feature estimates (G0 through post-ship) based on GPT-4o primary routing. These figures are baseline estimates established before VS Code 1.118 introduced prompt caching for Copilot Chat (April 2026). With caching active, actual Track A costs should be lower; log actuals at each gate close to calibrate. Ranges reflect normal complexity variation within each tier; anomalies trigger review, not a hard stop.
| Feature tier | Full feature cost | Anomaly threshold |
|---|---|---|
| Enhancement | $0.85–$2.60 | >$3.90 |
| New Capability | $1.95–$5.85 | >$8.78 |
| New Paradigm | $3.40–$10.60 | >$15.90 |
The base guide's three tiers (Haiku → Sonnet → Opus) map directly to OpenAI's model tiers in Copilot. The routing logic is identical — minimum sufficient model for the task. Under usage-based billing, every Chat interaction now consumes AI Credits, so over-routing to a high-capability model for a rule-based check has a direct dollar cost rather than a PRU budget cost. The optimization principle is unchanged; the consequence is now directly visible in your Billing Overview.
Direct equivalent of Haiku. Use for all deterministic tasks. GPT-4o mini consumes the fewest AI Credits per interaction and runs the fastest. This is the correct model for every pre-gate check and structured extraction in the FDLC — using GPT-4o or higher for these tasks wastes credits with zero quality benefit.
| Task | Copilot interface | Notes |
|---|---|---|
| Spec completeness / P7 sufficiency | Chat | Paste spec sections + P7 threshold table; output JSON result |
| Decision log gap scan | Chat | Paste amendment log + decision log; pattern match only |
| AC quality check | Chat | Three binary rules; no reasoning chain needed |
| DS compliance validation | Chat | Token list check against companion file DS-rules block |
| Gate checklist pre-population | Chat | Template fill from spec sections; deterministic |
| PR description generation | Chat | Structured template fill from unit brief |
| Cycle time extraction from git log | Chat | Structured data extraction from git log --format output |
Direct equivalent of Sonnet. The default model for all substantive FDLC work on Track A — code generation, spec-adjacent synthesis, structured document production. GPT-4o handles the majority of what Sonnet handles in Track B at a moderate per-token credit cost. The GPT-4o default rule: if unsure whether a task needs o1-mini, start with GPT-4o. If the reasoning quality is materially insufficient (not "less complete" — actually insufficient), escalate and log the reason. Note: GPT-4.1 and GPT-5 mini are designated as included models in GitHub's pricing — check current GitHub docs for whether these have preferential credit rates.
| Task | Copilot interface | Notes |
|---|---|---|
| Engineering build (per unit of work) | Chat or inline | Spec section + companion file + unit brief; single-unit per thread |
| Engineering spec draft | Chat | G3-approved inputs → structured engineering spec |
| G3 review brief | Chat | Feature folder synthesis; no novel judgment |
| Output suite — QA test cases | Chat | AC list → structured test case format |
| Copy / content generation | Chat | Within brand + DS constraints |
| Research synthesis (bounded) | Chat | Single corpus, clear task |
Use for tasks requiring genuine multi-step reasoning where the sequence of reasoning steps materially affects output quality. Not for tasks where GPT-4o produces sufficient output — GPT-4o is cheaper in AI Credit terms and equivalent in quality for bounded synthesis tasks. With usage-based billing, every unnecessary escalation to o1-mini now has a direct and visible credit cost.
| Task | Est. requests | Why o1-mini justified |
|---|---|---|
| Cross-domain spec alignment | 1–2 | Multi-spec conflict detection requires simultaneous reasoning across documents |
| AC implementability (complex features) | 1 | Non-trivial service dependency chain; GPT-4o misses edge cases |
| Spec gap analysis (New Paradigm) | 1–2 | Novel constraint space; gap identification requires reasoning chain |
| LLM-as-judge Tier B evaluation | 1 per eval | Rubric scoring requires explicit, auditable reasoning chain |
| Architecture decision record draft | 1–2 | High-stakes; tradeoff reasoning is the output |
Direct equivalent of Opus. Use only when the task requires highest-quality reasoning and the output consequence is high-stakes. With usage-based billing, o1 sessions are the most expensive interactions in the workflow and should be explicitly justified before each use.
| Task | Est. requests | Why o1 justified |
|---|---|---|
| New Paradigm design generation (if Design in Copilot) | 2–4 | Novel constraint space; design quality ceiling matters; Spec-First generation does NOT qualify |
| LLM-as-judge Tier C evaluation | 1 per eval | Highest rubric tier; design quality judgment requires most capable model |
| Dependency risk with conflicting signals | 1–2 | Multiple competing architectural concerns; o1-mini gives insufficient resolution |
Credit spend per phase depends on model selection and context size. The optimization goal is keeping high-token operations on the lowest-sufficient model tier and keeping context lean. The phase distribution below reflects expected credit concentration — not hard budgets. Calibrate against actual Billing Overview data after the first pilot features ship.
| Phase | Primary model | Credit concentration | Optimization lever |
|---|---|---|---|
| G0→G2 Spec authoring | GPT-4o mini for checks | Low | Keep all pre-gate checks on GPT-4o mini |
| G2→G3 Design generation | GPT-4o; o1-mini for LLM-as-judge | Medium | Sliding window / thread-per-unit; cache context blocks |
| G3→G4 Engineering build | GPT-4o primary | Medium–High | Thread-per-unit discipline is the highest-value lever here |
| Post-ship / governance | GPT-4o; o1-mini for ADR/judge | Low | Reserve o1-mini for ADR; synthesis on GPT-4o |
Track B implements a sliding window within a long session. Track A's equivalent is thread management: start a new Copilot Chat thread for each unit of work. Do not attempt to continue a multi-unit session in a single thread. The thread accumulation pattern is FM-A02 — the highest-leverage failure mode on Track A.
Use Copilot Chat's #file:path references instead of copy-paste wherever possible. They make context loading reproducible, reduce error, and produce an auditable input. Maintain section-level excerpts in the FDLC repo for the most commonly-needed context blocks:
| Agent category | What to load in Copilot Chat | Method |
|---|---|---|
| Rule-based checks (GPT-4o mini) | Relevant context-blocks/ excerpt + spec section only | #file: reference |
| Design generation (GPT-4o) | Companion file + spec.md + unit brief | #file: for companion + spec; brief in message |
| Engineering build (GPT-4o) | Engineering companion + spec §2.3/2.4/2.5 + unit brief | #file: + @workspace for codebase tasks |
| Post-ship analysis (GPT-4o) | Job statement (§1.2) + analytics plan (§5.x) only | #file: or section paste |
| Synthesis / research (GPT-4o) | Signal brief only — no constitution or companion file needed | Direct paste or #file: |
Under usage-based billing, cached tokens are billed at reduced credit rates — sources indicate 80–90% reduction for cached content. This makes caching discipline directly valuable, not just a Track B advantage. The key: structure every session so stable content (constitution block, companion file section) comes first — always in the same position and format — to maximize cache hit probability.
The base guide's Section 04 (MCP & Tool Use Discipline) does not apply to Track A. GitHub Copilot does not support MCP server integration. Textura MCP, Figma MCP, and all other MCP tools are Track B-only. The compensation pattern is context pack injection:
Maintain these as named text blocks in prompt-templates/track-a/context-blocks/ so engineers reference rather than reconstruct them. The per-session overhead of context pack injection is the Track A cost of not having MCP — it is a permanent operating cost, not a discipline gap.
GitHub Copilot supports a .github/copilot-instructions.md file at the repo root that provides lightweight persistent context — the closest Track A equivalent to CLAUDE.md. It does not enforce rules the way CLAUDE.md does, but it reduces cold-start overhead for naming conventions, the most critical constitution rules, and the engineering companion file summary.
The canonical source is prompt-templates/track-a/copilot-instructions.md in the FDLC repo. Feature repos copy from this source. When the constitution is amended, update this file in the same sprint as the companion file update.
The base guide's prompt engineering discipline applies without modification to Track A. Output format constraints, CoT rules, and the template standard are model-agnostic. This section covers only the Track A interface specifics that change how those principles are implemented.
| Interface | FDLC use | Cost note | When to use |
|---|---|---|---|
| Inline suggestions (autocomplete) | IDE productivity — not the workflow generation mechanism | Zero session setup; included in seat; no premium requests | Always on; no discipline required for this mode |
| Copilot Chat | Primary interface for all structured FDLC tasks | GPT-4o/mini included; premium models consume request budget | All pre-gate checks, generation, spec authoring, output suite |
| Copilot agent mode (@workspace) | Codebase-aware engineering build tasks | More premium requests than standard Chat — treat as expensive mode | Only when model needs to read existing code to produce output; not for checks or non-code tasks |
| Slash commands (/tests, /fix, /doc) | Narrow point tasks only; not substitutes for structured templates | Included in seat | /tests for simple unit stubs; /fix for point compilation errors; never for structured FDLC tasks |
Copilot Chat's markdown rendering wraps JSON in code fences by default, requiring additional parsing. Prevent this explicitly:
Track B's CLAUDE.md pre-loads context at project open. Track A's equivalent is a VS Code snippet for the session setup message — engineers type the shortcut and the snippet inserts the full context loading block. Store snippets in the FDLC repo, versioned alongside the prompt templates.
All nine failure modes from Section 05 of the base guide apply to Track A. Four have Track A-specific manifestations that are worth calling out explicitly. The base guide failure mode numbers are preserved for cross-reference.
The base guide's governance model applies with the following Track A modifications. Where a section maps directly, this is noted. Where Track A requires different operational specifics, they are defined below.
| FDLC phase | Track A viability | Track B gap | Track B advancement signal |
|---|---|---|---|
| Pre-gate checks (all phases) | Fully viable | Minimal — prompt-based checks are equivalent | Not a driver for Track B advancement |
| Spec authoring (G1→G2) | Fully viable | Low — agent assists work well in Chat | Not a driver |
| Design generation (G2→G3), single unit | Viable with discipline | Moderate — no MCP DS enforcement; context pack required | Generation stop rate >1/session consistently |
| Engineering build, 1–3 interdependent units | Viable with thread management | Moderate — CLAUDE.md persistence would reduce setup overhead | Session restart rate >2/unit; constitutional drift caught in review |
| Engineering build, 4+ interdependent units | Viable but overhead-heavy | High — manual context reload per unit compounds; drift risk rises | Post-G3 clarification overhead not improving; correction cycles rising with unit count |
| Multi-unit agentic sessions | Not recommended | Severe — constitutional context drift is structural, not discipline-fixable | Team attempting agentic sessions on Track A = immediate Track B case |