From an idea
to a safe release.

The working agreement: your voice, Sterling’s execution

Brad does not write code, run commands or diagnose a stack trace. Speak the whole vision in ordinary language. Sterling preserves it, organizes it into a product goal, smallest useful release, capability groups and ordered stories, and returns consequential questions. Brad owns intent, priorities, acceptable costs, privacy/business tradeoffs and release authorization. Sterling owns execution, traceability and truthful evidence; qualified specialists own technical judgments outside the agent’s assurance.

This standard applies to all our apps. It does not mean all this infrastructure already exists. For each app, inventory first and mark each control implemented, missing, not verified or not applicable with a reason. Establish missing infrastructure only under its own approved scope. The Visual Workflow remains the original educational map and dated case study; this tab is the fuller, risk-tailored operating policy. Neither is a live dashboard or a certification.

The product contract — the definition of “done”

Before a story starts, Sterling records the original voice wording, confirmed interpretation, users/roles, scope and non-goals, examples, forbidden outcomes, data/API contracts, dependencies, acceptance test IDs, risk and release authority. Keep a full-vision backlog so finishing a slice cannot silently erase later capabilities. A story is ready when consequential ambiguity is resolved, the environment and owner are known and the acceptance oracle is defined. It is done for its stated boundary only when implementation, relevant tests, review, documentation and acceptance evidence agree on the same revision. Local completion is not launch completion.

Repository-native requirements, feature/test traceability, architecture and operations documents are the governing record. Update them with feature, API, schema, configuration and release changes; keep an approved distribution mirror tied to the reviewed revision when required by the project. Sterling provides readable links and the exact decision sought, not a request that Brad inspect code.

One writer; durable handoffs

Give each specialist an exact repository/worktree/branch, allowed files, acceptance criteria and forbidden actions. Use one writer per owned surface, one integrator for the candidate, and one deployment lane per shared environment. Read-only review can run in parallel. A saved task list is not active execution: report verified complete, actively executing, queued and blocked separately. An interruption packet retains source identity, changed files, actual test results, unresolved decisions and the first deterministic resume action.

The end-to-end operating loop

Recommended implementation policy, risk-tailored per change—not a checklist mandated by any one source.

A. Capture intent before implementation

Founder speaks; agent structures; founder corrects. Capture the business outcome, users, what they can do, what must never happen, examples, timing, budget and what is explicitly out of scope. Preserve the original wording or a consented, short-lived transcript as the intake source; do not keep unnecessary voice recordings or secrets.

Create one decision log with: ID | original statement | proposed interpretation | confirmed/assumed/open/superseded | decision owner | revision/date. Confirm proper nouns, quantities, negations and permissions when a transcription ambiguity changes behavior, cost, integration or privacy. “I like the design” does not authorize production deployment.

Turn each confirmed requirement into observable acceptance criteria: Given [starting state], when [action], then [observable result]. Include unhappy paths, forbidden results and who can access which records. Ask only consequential questions now; keep later choices in an open-decision list.

Example, not a real customer record: “A coach can save a practice plan.” Clarify whether another coach may view it, whether saving requires an internet connection, and what a duplicate click does. Acceptance: a signed-in coach saves once, reloads and sees the plan; another unauthorized account cannot read or edit it; a failed save displays an honest retryable error; retry does not create a duplicate.

Maintain bidirectional traceability: REQ → acceptance criterion → risk/control → test ID → PR/commit → artifact/deployment → founder acceptance. A changed requirement invalidates affected tests and approvals, not necessarily every unrelated check. This adapts SSDF's risk-oriented planning and Microsoft's ADR discipline into founder-readable evidence.[2][7]

B. Discover the existing system and protect customer state

Before changing an existing production app, have the agent inventory and reconcile local worktree, GitHub repository/branch, CI configuration, beta hosting, production hosting, backend services, identity system and customer database. GitHub source history is not beta hosting and is not a backup of the live customer database. Do not assume a preview URL has separate data or secrets.

Record exact provider/account/project/environment/database IDs, deployed revision, configuration version, migration state and current service health. If the running app differs from source history, stop the proposed cutover and reconcile it; do not redeploy an older source version over live-only functionality. Establish characterization tests for behavior customers already rely on before refactoring.

For state-changing releases, define a recovery plan before mutation: what is backed up (database, files, configuration, identity dependencies), restore location, encryption/access, retention, dependency order, allowed data loss and recovery time. RPO means maximum acceptable data loss measured in time; RTO means maximum acceptable recovery duration. Microsoft recommends regular restore testing, not simply successful backup-job receipts.[19]

Restore into an isolated environment and check schema, representative application behavior and data-integrity invariants. Keep production writes out of that environment. Record achieved drill times and limits; a nonproduction drill does not prove real production failover timing. Refresh or verify a suitably recent recovery point at the approved cutover; for high-risk migrations, prevent or reconcile writes occurring after the snapshot. Never copy beta customer data over production.

C. Design just enough; make difficult decisions explicit

Draw one system/data-flow diagram showing trust boundaries, data stores, external providers, scheduled jobs and deployment ownership. List threats: unauthorized reads/writes, tenant crossover, impersonation, unsafe input, secret exposure, replay, duplicates, partial failure and dependency compromise. Select applicable ASVS controls and record exceptions with owner/rationale; legal/privacy duties need qualified advice where relevant.[2][3]

Write short ADRs only for decisions affecting structure, important quality attributes or reversibility: authentication approach, tenant/data isolation, build versus buy, service/provider boundary, migration strategy, consistency, backup and recovery. Each ADR includes context, options, decision, tradeoffs, consequences and revisit trigger. That scope follows Microsoft's ADR guidance.[7]

For privacy, explicitly choose collected fields, purpose, authorized roles, retention/deletion, logs, subprocessors and whether data leaves the system for an AI provider. Do not use real customer records in agent prompts or testing by default. A noncoding founder approves business/privacy tradeoffs; a qualified engineer validates sensitive technical controls.

D. Deliver one small vertical slice at a time

Build a thin useful path through interface, permissions, persistence and tests rather than completing every screen before the backend. DORA recommends small testable batches to shorten feedback loops, and frequent integration rather than long-lived divergent feature branches.[11][12]

Use a short-lived branch and a small PR. For multiple agents, use separate branches/worktrees with explicit task/file ownership. One integrator owns the target branch; one controlled deployment lane owns each shared environment. Do not let concurrent agents edit the same worktree, migration sequence or production resource without coordination. Review the merged candidate, not merely each isolated branch.

For new deterministic behavior and bug fixes, use red → green → refactor: demonstrate the expected failing behavior, implement the smallest change, then simplify while tests remain green. Google’s 2026 TDD guidance describes that cycle and explicitly says TDD is not a silver bullet.[24] For legacy code, characterize existing behavior first; for exploration, label the prototype nonproduction and add acceptance evidence before release.

E. Use a risk-shaped test portfolio

Google’s test-size terminology distinguishes small/isolated, medium/local integration, and large/system tests. Its 2010 resource/time limits are historical conventions, not values to copy blindly.[5] The pyramid is a heuristic; Google's newer SMURF guidance balances speed, maintainability, utilization, reliability and fidelity, not a fixed percentage distribution.[6]

For concurrency, explicitly test double submit, concurrent edits, stale versions, transaction conflicts, duplicate/out-of-order jobs or webhooks, retry after timeout, crash between write and acknowledgement, partial external success, and eventual reconciliation where the architecture permits those failures. Design idempotency keys, uniqueness constraints, optimistic locking or transactions as appropriate; do not promise “exactly once” merely because a queue supports retries. These are proposed risk scenarios, not a blanket requirement to use every mechanism.

Use an independently specified oracle: expected behavior comes from the requirement and invariant, not a copy of the implementation. Record seed/failing example for generated tests. A green test proving the wrong expectation is still wrong. Coverage and mutation percentages are diagnostics—not a numeric launch certificate.

F. Review independently, then enforce CI

Give a reviewing agent the requirement, diff, architecture/risk context and test evidence, and ask it to find omissions, unsafe assumptions and insufficient tests. Prefer read-only review and evidence-backed findings; the author resolves findings and records dispositions. A separate agent or model helps challenge assumptions but does not establish statistical independence or qualified human assurance. Shared prompts, models and context can share blind spots.

GitHub explicitly warns that Copilot can miss problems and produce false positives or insecure suggestions, and says its review should supplement human review.[9] The guide should not imply Brad must learn to code: Brad makes product and release decisions, while a qualified human engineer handles technical review of sensitive security, payments, destructive migrations, regulated/child data or unclear architecture. If such review is unavailable, narrow or defer that release instead of calling agent approval equivalent.

Recommended CI pipeline:

1. Reproducible install/build with pinned dependency resolution; lint, types and fast tests.
2. Changed-risk integration/contract tests and critical regression tests; security/dependency/secret checks appropriate to stack.
3. Build an immutable, identified deployable artifact; retain results, commit and configuration lineage.
4. Preview/staging deployment with synthetic fixtures and verified environment isolation.
5. Relevant end-to-end, accessibility, migration and recovery evidence.
6. Protected merge plus controlled production promotion of the reviewed candidate.

GitHub protected branches can require PR review, status checks and freshness of approvals. Its “passing” status-check rule accepts successful, skipped or neutral states; implement an explicit final verification job that fails if an intended required check never ran.[23] Confirm plan and repository eligibility before relying on environment approval gates. Listing several required reviewers means one approval can be sufficient, and self-review prevention is an explicit setting.[10]

DORA recommends tests before and after merging and authoritative, repeatable build packages used downstream.[12] If merge changes the candidate, rerun affected checks and bind approval to the resulting revision. If merging triggers production automatically, place the release gate before merge; otherwise a later approval is theater.

G. Founder acceptance and bounded release approval

Show Brad a clickable preview, short scenario checklist and evidence scorecard. Ask two separate questions:

• Product acceptance: “Does this version solve the agreed problem and behave correctly in these scenarios?”
• Release authorization: “May this exact revision be promoted to this production project, with this data/configuration change, exposure limit, cost ceiling and rollback plan?”

Aesthetic acceptance is not technical verification; technical verification is not release permission. Founder approval does not waive unresolved security or data-loss blockers.

Before promotion, lock source/artifact/configuration/migration identifiers; verify recovery readiness and production bindings. Use progressive exposure or a bounded canary when meaningful for the architecture. SRE defines a canary as a partial, time-limited change plus evaluation, and Microsoft calls for health checks and immediate halt/recovery when problems are detected.[13][8] A preview URL is not a canary, and a low-traffic app may not provide enough statistical evidence; use a controlled rollout with explicit synthetic/business checks and state that limitation.

H. Verify the provider and the user experience separately

The release receipt should bind: approved revision → artifact → provider account/project → deployment ID/status → environment bindings/config → production hostname → migration version → verification timestamp.

Read the provider's authoritative deployment state, then exercise the actual production URL and critical operation. Verify authentication/authorization, persisted read-back, relevant integration outcome and logs/metrics. A CLI exit code, HTTP 200, screenshot or green CI badge alone is not end-to-end proof. Distinguish implemented locally / CI verified / staged / founder accepted / deployed / live verified / recovery verified.

Code rollback, feature disabling, database restore and business compensation are different operations. A previous app version may not understand a new schema, and reverting code cannot undo a sent email, charged payment or deleted record. Prefer backward-compatible expand/migrate/contract changes when feasible; retain both-version compatibility during rollback windows. Microsoft explicitly warns that stateful rollbacks are complex.[8] Define whether the safe response is disable, roll back, roll forward, restore or compensate, who may execute it, and what new writes could be lost.

I. Operate, learn and maintain

Name an owner and reachable incident contact; an agent process is not an on-call organization. Set service objectives that reflect business needs, and alert on actionable symptoms. SRE's four golden signals are latency, traffic, errors and saturation.[16] Add domain signals such as failed saves, duplicate jobs or authorization denials when they reveal meaningful risk; minimize sensitive log content and control retention/access.

Incident playbook: detect → assess impact → contain risky activity → mitigate/recover → verify customer outcomes → communicate → preserve evidence → investigate → assign prevention work. Keep a timestamped record and avoid multiple uncoordinated responders changing the same system. SRE postmortems document impact, mitigation, contributing causes and preventive follow-up, using a blameless approach.[15]

Maintain dependency/security updates, secret/access reviews, restore drills, regression tests, accessibility checks on changed flows, provider/API compatibility, operating cost limits and retirement of obsolete flags/resources. Set cadence by risk and ownership, not “run every test every hour.” Review recurring incidents and test flakiness; turn real defects into regression tests. Stop feature release when a relevant critical gate is red; fix or narrow scope rather than conceal skipped tests.

Frontend Code Verification Protocol

This is our proposed execution contract, not an external standard. Use it with the risk-shaped test portfolio in the operating loop above. It covers a static screen as well as an app with APIs, but marks genuinely absent boundaries N/A rather than inventing them.

1. Inventory the release scope. Lock frontend/backend/configuration artifacts. List every function entry point, event handler, generated handler, call chain and API route in the agreed scope. If the assignment is full-app QA, the denominator is the full app—not only changed functions.
2. Trace the whole chain. Input → validation → permission → state mutation → serialization → request → backend ownership/schema check → persistence → response parsing → rendering → saved-state reload/export. Enumerate early returns, bailouts, catches/finally, cancellation, invalid/missing/legacy data, timeout, offline and retry paths.
3. Build a branch ledger. For each branch: source/function, precondition, expected effect or forbidden effect, test ID, actual result, environment and evidence. Status is PASS, FAIL, BLOCKED or NOT TESTED. Unexecuted is never passed. Keep coverage denominators explicit; executed bytes are not proof of every outgoing branch outcome.
4. Verify the real boundary. Sterling checks appropriate authorized API endpoints for HTTP status, content type and JSON shape, including authentication errors and HTML single-page-app fallback masquerading as JSON. Connect UI actions to backend writes and persisted read-back. Mock responses, source inspection and screenshots cannot establish that a provider integration works.
5. Exercise representative devices and failures. Include desktop/mobile Chromium and WebKit, touch/keyboard, focus, loading/empty/error states, manual edits, reload/new-session persistence, export/print and concurrent edits where applicable. Screen-reader and zoom evaluation complement automation; do not claim WCAG conformance from this subset.
6. Bound side effects. Use isolated fixtures for destructive/provider branches unless the exact live action is authorized. Suppress outbound actions on the server as well as the browser. Use Brad’s standing approved test inboxes under the authorized test purpose; keep the actual addresses in private configuration. Never publish test addresses, customer IDs or customer records in this guide. Track created synthetic objects privately and verify cleanup of only those objects.
7. Close the release ledger. Rerun affected chains and final gates after any edit. Every branch in the agreed release scope must have the required evidence before release; blocked and untested required branches stop it. Explicitly narrow scope with approval rather than silently waiving a missing branch. This is bounded verification, not a promise to test every possible permutation, timing or unknown failure.

Multi-device saves: compare-and-swap (CAS), not wishful retry

CAS means “save only if the server still has the revision I edited.” The version check and write must be atomic at the database boundary. A read followed by an unconditional write is not conflict-safe. Test two devices editing the same starting version: one accepted write; the stale write is rejected or explicitly reconciled without overwriting newer work. Cover late responses arriving after newer edits, account/team changes, offline drafts, deletion tombstones, duplicate submissions, and transaction rollback where applicable. Never clear a newer local draft because an older save returned. If the backend lacks an atomic precondition, preserve the draft separately and expose the conflict; do not call it synchronized. These are recommended risk scenarios, not claims that Math Ballpark or Dugout implements CAS today.

Two voice-to-proof mini examples

Illustrative only — proposed behavior and tests, not completed features or real customer data.

Math Ballpark / a first working skeleton

Voice: “Let a child count baseballs, choose an answer and try again if it’s wrong.”

Confirm: Sterling asks for the learner level, allowed number range, what “try again” means and whether progress must persist. Do not infer a curriculum, reward system or child-data permission from this sentence.

Small vertical slice: one playable counting scene → answer selection → correct/wrong feedback → return to the next question. A skeleton means this smallest honest end-to-end path, not a polished shell with fake save success. If persistence is out of this slice, say so visibly; if required, include real storage and reload proof.

Acceptance: Given a scene in the confirmed range, when the learner chooses an answer, the visible count and independently computed correct answer agree. A wrong answer never advances the score; a correct answer advances once, including after repeated clicks. Touch and keyboard controls fit a phone; reduced motion remains usable. Existing modes and saved progress remain intact.

Sterling’s proof: deterministic boundary examples, generated invariants over the declared range, an independently specified answer oracle, real browser correct/wrong/retry journey and regression evidence. Brad watches the preview and decides whether the instructions and feedback make sense. A qualified educator’s suitability review is separate from mathematical consistency.

Dugout / save a practice plan without losing another coach’s work

Voice: “A coach can save a practice plan and come back to it on another device.”

Confirm: whose team can view/edit it, offline expectations, conflict handling and existing plan/history preservation. “Another device” does not authorize a new shared-login architecture.

Acceptance: Given an authorized synthetic coach, saving once then reloading on another authenticated device shows the same plan. An unauthorized team cannot read or edit it. A failed save displays an honest recoverable error; retry does not duplicate the plan. Two edits from one version cannot silently overwrite each other. A late response cannot erase a newer draft. Existing team membership, rosters, games, plans and history survive the change.

Sterling’s proof: unit permission/rule tests, real isolated database/API tests, response-contract checks, two browser contexts for the stale-save race, and named end-to-end save → reload → other-device → forbidden-team journeys. Run the change against representative legacy state, not just an empty database. Live verification uses only approved synthetic records and private test-inbox configuration. Brad approves product behavior and separately the exact production cutover; no customer database is replaced by beta data.

Release states: use the exact words

A release receipt includes requirement and risk coverage, test commands/results, candidate/artifact/configuration/migration IDs, reviewer findings, preview, provider target, backup/restore evidence, unresolved noncritical risks and the precise approval sought. Keep sensitive environment identifiers in the private packet, not on this educational page.

The risk ledger is not a green badge

Record risk ID | requirement | failure/impact | likelihood rationale | control/test | result | residual risk | accountable owner | review trigger. Block on serious security exposure, potential silent data loss, unclear target, missing required evidence or absent release authority. Brad may accept explained noncritical business risks; he is not asked to certify unfamiliar security controls. Independent AI review is useful challenge, not equivalent to qualified human security review. Narrow or defer a sensitive release if that review is unavailable.

Protect active customers through recovery

Preserve whole customer teams and their related records, not just login accounts. Characterize live-only behavior before refactoring. Restore a backup into isolation, verify referential integrity and representative workflows, then refresh protection at the approved cutover. Coordinate or reconcile writes after the snapshot. Favor expand → migrate → contract with old/new version compatibility during the rollback window. Code rollback, database restore, feature disable and business compensation are different actions. A restore that discards newer customer activity requires a separate explicit decision; a sent email or payment is not undone by reverting Git.

Founder decisions: no code required

Do not ask Brad to approve a vague “architecture/testing/deploy everything” bundle. When technical competence is needed, the decision is to obtain qualified review—not to make the founder rubber-stamp unfamiliar code.

Evidence scorecard: confidence without a fake total

Proposed scale per row: 0 = absent/unknown; 1 = documented only; 2 = executed in representative nonproduction; 3 = verified at the relevant live boundary or realistic recovery exercise. Mark N/A only with a reason. Keep the artifact link, exact revision/environment, timestamp, owner and limitations beside every score. Do not sum these into a percentage of safety. A level 3 statement proves only the boundary actually exercised; requirement confirmation uses decision receipts rather than runtime tests.

Proportionality: a copy-only page edit needs identity, review/build checks, relevant visual/accessibility checks and live read-back; it does not automatically need a database restore rehearsal. An authentication or financial change needs targeted negative/security tests and qualified review. A customer-data migration needs compatibility, concurrency/write coordination, integrity and recovery evidence. The release gate follows the change's risk and blast radius, not a universal maximum checklist.[2][8]

How to read the sources

• NIST SSDF: use SP 800-218 / SSDF 1.1, February 2022 as the final baseline. The current NIST registry lists SSDF 1.2 / Rev. 1 as a draft, and its publication page identifies an initial public draft dated December 17, 2025. Do not silently promote it to a final requirement.[1][18]
• SSDF explicitly says its intention is not to create a checklist; relevant practices should be selected by risk, cost, feasibility and applicability. Its guidance can be adopted voluntarily by nongovernmental organizations; a procurement contract or other obligation may separately require it.[2]
• OWASP ASVS 5.0.0 is the stable version reported by the official project. It is a technical security-verification standard and procurement aid. Pin versioned requirement IDs in the project security plan; selected checks are not evidence of complete ASVS conformance.[3]
• WCAG 2.2 is a W3C Recommendation; the retrieved Recommendation is dated December 12, 2024. Level AA conformance requires all Level A and AA criteria, subject to its full-page, complete-process and other conformance requirements. The specification anticipates automated testing plus human evaluation. A scanner pass or a few keyboard checks is not a WCAG conformance determination.[4]
• Google Testing, Microsoft Well-Architected, DORA and Google SRE provide engineering guidance, operational patterns or research-informed recommendations—not one mandatory certification framework.[5][8][11] DORA, Google Testing and Google SRE are not three independent corporate authorities.
• GitHub docs establish specific product behavior, limitations and plan-dependent controls. Hypothesis, Pact and Stryker docs explain their testing techniques; their tooling claims do not establish a universal release guarantee.[9][10][20]

This operating policy is synthesis, not an application audit, legal opinion or certification. Voice intake, ownership, branch ledgers, concurrency scenarios and the scorecard are our recommended practices. Sources were inspected September 13, 2026. Recheck living documentation and provider entitlements before implementation. Google Testing, DORA and SRE share corporate affiliation; GitHub and Microsoft are also affiliated.

Sources & applicability — 23 inspected references

Original research identifiers are retained (there is no source 14). These links support the stated guidance, not claims that our apps passed it.

1. NIST — Registry retrieved 2026-09-13

   Publication status. Use to distinguish final baseline from draft.

2. NIST — SSDF 1.1; SP 800-218, February 2022

   Recommendations. Risk-tailor secure development rather than claim certification.

3. OWASP — ASVS 5.0.0 stable

   Open verification standard. Pin version and selected requirement IDs; selection is not whole-standard conformance.

4. W3C — WCAG 2.2, Recommendation 12 December 2024

   Normative web standard. AA claims require all A and AA criteria plus conformance requirements; combine manual and automated evaluation.

5. Google Testing — Test Sizes, 13 December 2010

   Engineering guidance. Distinguish test isolation/resource size from test purpose; historical limits are not universal mandates.

6. Google Testing — SMURF, 15 October 2024

   Engineering guidance. Balance speed, maintainability, utilization, reliability, fidelity; no mandatory test ratios.

7. Microsoft — Living Azure Well-Architected documentation

   Architecture guidance. Write ADRs for significant or hard-to-reverse decisions, not every coding detail.

8. Microsoft — Living Azure Well-Architected OE:11

   Operational guidance. Progressive delivery, health checks and explicit stateful recovery.

9. GitHub — Living Copilot Agents application card

   Product limitations and safety guidance. Agent review supplements rather than replaces human code review.

10. GitHub — Living GitHub Actions environments documentation

    Product behavior. Verify plan/repository eligibility and actual approval enforcement; multiple listed reviewers are not multiple required approvals.

11. DORA (Google) — Living small-batches capability

    Research-informed capability guidance. Small testable increments and feedback; association is not a guarantee for this team.

12. DORA (Google) — Living CI capability

    Research-informed capability guidance. Fast feedback and frequent integration; CI is more than owning a runner.

13. Google SRE — SRE Workbook, Canarying Releases

    Operational practice. Limited exposure with evaluation; no test method is a panacea.

15. Google SRE — SRE book, Postmortem Culture

    Operational practice. Incident learning tied to owned prevention actions.

16. Google SRE — SRE book, Monitoring Distributed Systems

    Operational practice. Monitor latency, traffic, errors, saturation plus product-specific correctness.

17. NIST — ACTS project, living overview

    Research and testing technique. Risk-selected combinatorial interaction coverage; not proof of all permutations.

18. NIST — SSDF 1.2; SP 800-218 Rev. 1 initial public draft, 17 December 2025

    Draft recommendations. Track changes but do not label this final.

19. Microsoft — Living Azure Well-Architected DR documentation

    Reliability guidance. Choose RPO/RTO and prove restore; nonproduction drill is not proof of full production RTO.

20. Hypothesis maintainers — Living Hypothesis documentation; Python implementation

    Tool documentation. Generated bounded-domain inputs complement examples, not exhaustive verification.

21. Pact maintainers — Living Pact introduction

    Tool documentation. Consumer-provider compatibility; cannot prove all operational behavior.

22. Stryker maintainers — Living Stryker mutation-testing introduction

    Tool documentation. Check whether tests detect seeded changes; use selectively and inspect surviving mutations.

23. GitHub — Living protected-branches documentation

    Product behavior. Protection can accept skipped or neutral; explicit evidence aggregator must ensure intended tests ran.

24. Google Testing — The Way of TDD, 10 March 2026

    Engineering guidance. Use red-green-refactor for behavioral slices; TDD is not sufficient release assurance.

Back to methodology ↑ · See the original release flowchart →