# BlueMesa checkout release

**Case packet version:** 2026.08.31-practice-3

This is a fictional, sanitized software-quality case. All systems, users, transactions, and records are fabricated; testing remains authorized and bounded and provides no security, legal, accessibility, or defect-free guarantee.

## Case brief · CB01

BlueMesa is a fictional business-to-business storefront preparing release 4.8 of its checkout. The approved requirement says authenticated buyers may purchase approved catalog items up to their account credit limit, apply one active contract discount, choose an allowed shipping method, and receive an accessible confirmation. The release candidate is build 4.8.17 in staging. Six browsers and two mobile devices are in scope, but the test plan lists only the latest desktop Chrome. A sample account has a $10,000 credit limit and an existing $9,600 open balance. The cart contains a $700 item, a 10 percent contract discount, $55 shipping, and an 8.25 percent tax rule. The product owner expects the order to be blocked, while the developer says discounts should be considered before the credit check; the requirement does not state calculation order. In preliminary testing, the keyboard focus disappears after the shipping modal closes, the error summary is not announced by the screen reader, and refreshing after payment timeout sometimes creates a second pending order. Logs show the same idempotency key on both requests, but the payment sandbox returns different response identifiers. The tax service was upgraded after the last regression baseline. A defect titled checkout broken includes no build, data, steps, expected result, actual result, or evidence. Marketing already announced Friday availability, and the release manager proposes accepting all medium defects. Learners must define risk and acceptance, control environments, write reproducible tests, explore edge cases within authority, classify defects, and make an evidence-bounded release recommendation. They must not conduct unapproved security testing or claim exhaustive coverage.

## Case record

- **F01 · confirmed:** The release candidate is build 4.8.17 in staging.
- **F02 · confirmed:** Six browsers and two mobile devices are in scope, while the plan covers one desktop browser.
- **F03 · confirmed:** The sample account has a $10,000 limit and a $9,600 open balance.
- **F04 · confirmed:** The cart includes a $700 item, ten-percent discount, $55 shipping, and 8.25-percent tax rule.
- **F05 · conflicting:** Product and development owners disagree about the credit-check calculation order.
- **F06 · unknown:** The approved requirement does not define the calculation order.
- **F07 · confirmed:** Keyboard focus disappears after the shipping modal closes.
- **F08 · confirmed:** The error summary is not announced by the screen reader.
- **F09 · confirmed:** Refreshing after payment timeout can create a second pending order.
- **F10 · conflicting:** Duplicate requests share an idempotency key but receive different sandbox response identifiers.
- **F11 · confirmed:** The tax service changed after the prior regression baseline.
- **F12 · confirmed:** The existing checkout-broken defect lacks reproducibility and expected-result evidence.

## Module assignments and operating guides

### Module 1 — Define acceptance and risk

**Task mode:** bounded-case-starter

Translate the requirement and known uncertainty into testable criteria and release risks.

**Deliverable:** An acceptance-criteria table and quality-risk register.

**Provided inputs**

- **M01-I01 · case-fact · F03:** The sample account has a $10,000 limit and a $9,600 open balance.
- **M01-I02 · case-fact · F04:** The cart includes a $700 item, ten-percent discount, $55 shipping, and 8.25-percent tax rule.
- **M01-I03 · case-fact · F05:** Product and development owners disagree about the credit-check calculation order.
- **M01-I04 · case-fact · F06:** The approved requirement does not define the calculation order.
- **M01-I05 · case-fact · F07:** Keyboard focus disappears after the shipping modal closes.
- **M01-I06 · case-fact · F08:** The error summary is not announced by the screen reader.
- **M01-I07 · case-fact · F09:** Refreshing after payment timeout can create a second pending order.
- **M01-B01 · case-brief · CB01:** Use CB01, the full versioned case brief printed once at the start of this packet, as a citable narrative source for details not normalized into F01–F12. Preserve its uncertainty language and do not treat narrative detail as approval, complete operational records, or professional judgment.
- **M01-S01 · assignment-scope · F03, F04, F05, F06, F07, F08, F09:** Build a starter version of “An acceptance-criteria table and quality-risk register.” from the listed case facts. Treat requested structures, controls, questions, calculations, and templates as learner-designed proposals. Where an operational record or result is absent, add a gap entry naming the missing evidence and authorized owner instead of fabricating it.

**Completion boundary**

Complete a bounded starter and gap analysis using only CB01, F03, F04, F05, F06, F07, F08, F09, and the assignment-scope record below. Populate supported fields, label every unavailable field “not supplied,” and cite the input ID for each material statement. You may design a proposed template, control, question, or decision rule, but must label it as a learner proposal rather than observed case evidence. Do not contact people, access live systems, run tests, sign records, claim approval, or invent names, dates, quotations, transactions, results, or source documents.

**Workbook plan:** M01-WP01 · 2026.09.01-workbook-plan-2

### Prerequisite check

- [ ] Confirm F03-F09; record that the approved credit-check order, expected duplicate-request behavior, complete accessibility acceptance standard, and release decision are not supplied.
- [ ] STOP. If calculation order, duplicate-request behavior, accessibility acceptance, or the release decision is missing or conflicts across F03–F09, route the criterion to authorized product, payments/finance, engineering, accessibility, and QA owners; do not claim acceptance approval, test execution, pass/fail, or release.

### Operating procedure

1. Capture account, cart, tax, requirement-conflict, accessibility, and duplicate-order facts with source IDs.
2. Separate supplied observations from proposed acceptance rules.
3. Write each criterion as observable given/when/then behavior with a single pass condition.
4. Show formula operands and rounding points, but keep the expected credit decision pending because calculation order is undefined.
5. Add keyboard-focus, screen-reader-summary, and timeout-refresh criteria.
6. Assign product, engineering, accessibility, payments, and QA reviewers to unresolved decisions.
7. Final-QC for traceability, ambiguity, negative paths, environment assumptions, and no invented pass result.

### Field-by-field guidance — M01-A01

| Field | What high-quality completion requires |
|---|---|
| Criterion ID | Assign a stable training criterion ID linked to one supplied requirement, observation, or decision gap. |
| Given state | State only packet-supplied preconditions and values. |
| Action | Describe one bounded user/system action to be tested; do not claim execution. |
| Expected observable result | State the observable pass condition or explicitly record a decision gap when the requirement is unresolved. |
| Formula or rounding rule | Show supplied operands and the approved rule; use Not supplied when order or rounding is undefined. |
| Environment | Record a supplied environment or Not supplied; do not invent browser, device, or build evidence. |
| Source IDs | Cite exact module input and fact IDs supporting the criterion. |
| Requirement status | Use Confirmed, Conflicting, Not supplied, or Proposed — review pending. |
| Owner | Name the authorized product, engineering, accessibility, payments, or QA role. |
| Test status | Use Not run, Blocked, Draft, or another evidence-backed state; never invent a pass. |

### Completed supported example — M01-A01

**Reference only.** This row demonstrates supported evidence and truthful status; it is not a learner submission or proof of live work.

| Criterion ID | Given state | Action | Expected observable result | Formula or rounding rule | Environment | Source IDs | Requirement status | Owner | Test status |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| AC-CREDIT-01 | $10,000 limit; $9,600 open balance; cart has a $700 item, ten-percent discount, $55 shipping, and an 8.25-percent tax rule. | Learner-proposed check of the credit decision using an approved calculation sequence. | Decision gap — expected approval/decline result cannot be fixed until the calculation order is approved. | Operands are supplied; calculation order and rounding points are not supplied because product/development disagree and the requirement is undefined. | Not supplied | M01-I01 (F03); M01-I02 (F04); M01-I03 (F05); M01-I04 (F06) | Conflicting / not supplied | Product owner with engineering and QA review | Blocked — requirement decision pending |

### Completed known-gap example — M01-A01

**Reference only.** This row demonstrates how to preserve missing evidence without inventing a result.

| Criterion ID | Given state | Action | Expected observable result | Formula or rounding rule | Environment | Source IDs | Requirement status | Owner | Test status |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| AC-FOCUS-02 | Keyboard focus disappears after the shipping modal closes. | Close the shipping modal using a keyboard in an approved test environment. | Approved focus-return target and observable focus state are not supplied. | Not applicable | Browser, OS/device, viewport, input method, and build evidence not supplied. | M01-I05 (F07) | Observed defect; acceptance target incomplete | Accessibility reviewer and frontend engineering owner | Not run — environment and expected target pending |

### Supporting artifact build sequence

1. **M01-A02 · Quality-risk register** — Produce a bounded, reviewable quality-risk register from cited packet evidence while exposing unsupported fields and required approvals. Build 2 rows from M01-I02, M01-I05, M01-I07 and address M01-EC02. Use only the scoped case-fact inputs below. Cite an input ID for each supported statement; label proposed structures “learner proposal” and unavailable evidence “not supplied.”

### Completed supporting-artifact examples

#### M01-A02 · Quality-risk register

**Reference-only completed row.** Use it to understand the evidence boundary; do not present it as your own completed work.

**Criterion demonstrated:** M01-EC02

**Why this row is included:** The canonical M01-A02 route maps M01-EC02. This single risk-register row ranks all four named risk families from the supplied observations and labels the priority order as a learner proposal pending authorized review.

| Entry ID | Issue or event | Evidence and source ID | Risk or impact | Owner | Bounded next step | Review point | Status |
| --- | --- | --- | --- | --- | --- | --- | --- |
| QRISK-01 | Learner-proposed ranking: Priority 1 payment/order duplication; Priority 2 credit-enforcement and tax-calculation uncertainty; Priority 3 keyboard and screen-reader accessibility failure. | M01-I07 (F09); M01-I01 (F03), M01-I02 (F04), M01-I03 (F05), and M01-I04 (F06); M01-I05 (F07) and M01-I06 (F08) | A refresh can create a second pending order; undefined calculation order can produce an unsupported credit or tax decision; missing focus and error announcement can block keyboard and screen-reader users. Relative likelihood, severity, and owner acceptance are not supplied. | Product, payments, tax/finance, accessibility, engineering, and QA owners | Have authorized owners confirm severity and order, resolve the calculation oracle, and approve safe evidence-based tests; do not process a real payment in this exercise. | Before release approval and before any live payment test | Draft ranking — owner review and test evidence pending |

### Stop / Go / Escalate

| Decision | Rule |
|---|---|
| **Stop** | Stop pass/fail or release claims when the requirement, formula, environment, or expected state is disputed or absent. |
| **Go** | Proceed to test design when each criterion has cited inputs, observable behavior, and an authorized owner for gaps. |
| **Escalate** | Escalate money calculations, duplicate-order behavior, and accessibility acceptance to product, finance/payments, engineering, and accessibility owners. |

### Completion test

- [ ] Money, accessibility, duplicate, and recovery criteria are observable and traceable.
- [ ] Disputed calculation order remains an explicit blocker.
- [ ] No test result or product approval is fabricated.

### Artifact map

- **M01-A01 · Acceptance-criteria table:** Produce a bounded, reviewable acceptance-criteria table from cited packet evidence while exposing unsupported fields and required approvals. Expected rows: 6. Criteria: M01-EC01, M01-EC03, M01-EC04. Scoped inputs: M01-I01, M01-I03, M01-I04, M01-I06, M01-I02, M01-I05, M01-I07.
- **M01-A02 · Quality-risk register:** Produce a bounded, reviewable quality-risk register from cited packet evidence while exposing unsupported fields and required approvals. Expected rows: 2. Criteria: M01-EC02. Scoped inputs: M01-I02, M01-I05, M01-I07.

### Evidence criteria

- **M01-EC01:** Identifies the missing calculation-order decision as a requirement gap
- **M01-EC02:** Ranks payment duplication, credit enforcement, tax, and accessibility risks
- **M01-EC03:** Names the authorized owner for expected-behavior decisions
- **M01-EC04:** Cites the supplied input IDs for material statements and marks omitted operational records or results “not supplied” rather than fabricating them

### Module 2 — Control test conditions

**Task mode:** bounded-case-starter

Design an environment and data matrix that represents the approved scope and dependencies.

**Deliverable:** A test-plan matrix with builds, devices, browsers, roles, data, services, and reset method.

**Provided inputs**

- **M02-I01 · case-fact · F01:** The release candidate is build 4.8.17 in staging.
- **M02-I02 · case-fact · F02:** Six browsers and two mobile devices are in scope, while the plan covers one desktop browser.
- **M02-I03 · case-fact · F11:** The tax service changed after the prior regression baseline.
- **M02-B01 · case-brief · CB01:** Use CB01, the full versioned case brief printed once at the start of this packet, as a citable narrative source for details not normalized into F01–F12. Preserve its uncertainty language and do not treat narrative detail as approval, complete operational records, or professional judgment.
- **M02-S01 · assignment-scope · F01, F02, F11:** Build a starter version of “A test-plan matrix with builds, devices, browsers, roles, data, services, and reset method.” from the listed case facts. Treat requested structures, controls, questions, calculations, and templates as learner-designed proposals. Where an operational record or result is absent, add a gap entry naming the missing evidence and authorized owner instead of fabricating it.

**Completion boundary**

Complete a bounded starter and gap analysis using only CB01, F01, F02, F11, and the assignment-scope record below. Populate supported fields, label every unavailable field “not supplied,” and cite the input ID for each material statement. You may design a proposed template, control, question, or decision rule, but must label it as a learner proposal rather than observed case evidence. Do not contact people, access live systems, run tests, sign records, claim approval, or invent names, dates, quotations, transactions, results, or source documents.

**Workbook plan:** M02-WP01 · 2026.09.01-workbook-plan-2

### Prerequisite check

- [ ] Confirm F01, F02, and F11; record that browser/device versions, operating systems, assistive-technology combinations, test accounts, data reset method, and approved coverage priority are not supplied.
- [ ] STOP. If environment versions, assistive-technology coverage, test accounts, data reset, or coverage priority is missing or conflicts with F01/F02/F11, route the matrix to authorized QA, product, and accessibility owners; do not claim coverage approval or execute testing.

### Operating procedure

1. Freeze build 4.8.17 as the version under design review.
2. Enumerate all six browser and two mobile-device slots instead of collapsing them into one desktop row.
3. Add operating system, viewport/input method, assistive technology, locale, and network-state fields as not supplied where absent.
4. Map checkout risks to each proposed environment using a risk-based rationale.
5. Include the changed tax service as a dependency and baseline-reset trigger.
6. Define setup, data reset, evidence capture, and blocked-environment handling.
7. Final-QC coverage counts, version traceability, dependency state, owners, and pending execution.

### Field-by-field guidance — M02-A01

| Field | What high-quality completion requires |
|---|---|
| Environment ID | Assign one stable row ID per planned environment slot. |
| Build | Record the supplied build identifier and source ID or Not supplied. |
| Browser/version | Record the approved browser/version or Not supplied; do not invent scope values. |
| OS/device | Record the approved OS/device combination or Not supplied. |
| Viewport/input | Record viewport and keyboard/touch/pointer coverage or Not supplied. |
| Assistive technology | Record the approved assistive-technology/version pairing or Not supplied. |
| Locale/network | Record locale and network condition or Not supplied. |
| Dependency version | Record material dependency/baseline versions, including tax-service status, or Not supplied. |
| Risk coverage | Map the row to a cited scope/risk and state what remains uncovered. |
| Evidence location | Name the planned evidence location; leave it pending because tests were not run. |
| Owner | Name the authorized QA or specialist-review role. |
| Status | Use Planned — approval pending, Blocked, or Not supplied; never claim execution. |

### Completed supported example — M02-A01

**Reference only.** This row demonstrates supported evidence and truthful status; it is not a learner submission or proof of live work.

| Environment ID | Build | Browser/version | OS/device | Viewport/input | Assistive technology | Locale/network | Dependency version | Risk coverage | Evidence location | Owner | Status |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| ENV-01 | 4.8.17 staging — M02-I01 (F01) | Not supplied | Desktop combination not supplied | Keyboard coverage proposed; viewport not supplied | Not supplied | Not supplied | Tax service changed after the prior baseline — M02-I03 (F11) | One of at least eight planned slots; exact six-browser/two-mobile combinations remain unspecified — M02-I02 (F02). | Pending — test execution is outside this exercise | QA lead | Draft — environment details not supplied |

### Completed known-gap example — M02-A01

**Reference only.** This row demonstrates how to preserve missing evidence without inventing a result.

| Environment ID | Build | Browser/version | OS/device | Viewport/input | Assistive technology | Locale/network | Dependency version | Risk coverage | Evidence location | Owner | Status |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| ENV-02 | 4.8.17 staging — M02-I01 (F01) | Not supplied | Mobile device model and OS not supplied | Touch and responsive viewport details not supplied | Not supplied | Not supplied | Current tax-service version not supplied | Mobile scope exists, but the approved pairing and expected results are not supplied — M02-I02 (F02). | Not supplied | QA lead and accessibility reviewer | Blocked — environment definition pending |

### Supporting artifact build sequence

This module has no separate supporting artifact; complete the principal artifact and its decision record.

### Completed supporting-artifact examples

No additional completed supporting-artifact row is supplied. Use the supporting artifact instructions, scoped inputs, completion checks, and known-gap method above; keep unsupported cells marked **not supplied**.

### Stop / Go / Escalate

| Decision | Rule |
|---|---|
| **Stop** | Stop execution or coverage claims when build, environment, dependency, test data, or evidence-capture state is unknown. |
| **Go** | Proceed when every in-scope slot has a reproducible setup and risk rationale. |
| **Escalate** | Escalate inaccessible environments, dependency drift, and scope reductions to QA/product/accessibility owners. |

### Completion test

- [ ] Six browser and two mobile-device slots are explicitly represented.
- [ ] Build and tax-service versions are controlled.
- [ ] No environment is represented as executed.

### Artifact map

- **M02-A01 · Cross-environment test-plan matrix:** Produce a bounded, reviewable cross-environment test-plan matrix from cited packet evidence while exposing unsupported fields and required approvals. Expected rows: 8. Criteria: M02-EC01, M02-EC02, M02-EC03, M02-EC04. Scoped inputs: M02-I01, M02-I02, M02-I03.

### Evidence criteria

- **M02-EC01:** Covers all scoped browser and mobile classes using risk-based rationale
- **M02-EC02:** Versions the payment and tax dependencies
- **M02-EC03:** Provides repeatable data setup and cleanup without real payment data
- **M02-EC04:** Cites the supplied input IDs for material statements and marks omitted operational records or results “not supplied” rather than fabricating them

### Module 3 — Write reproducible evidence

**Task mode:** bounded-case-starter

Create tests for credit calculation, payment timeout, and accessible error handling.

**Deliverable:** Six test-case designs, two evidence starters for the observed accessibility and duplicate-order issues, and result-pending fields for every unexecuted case.

**Provided inputs**

- **M03-I01 · case-fact · F03:** The sample account has a $10,000 limit and a $9,600 open balance.
- **M03-I02 · case-fact · F04:** The cart includes a $700 item, ten-percent discount, $55 shipping, and 8.25-percent tax rule.
- **M03-I03 · case-fact · F05:** Product and development owners disagree about the credit-check calculation order.
- **M03-I04 · case-fact · F06:** The approved requirement does not define the calculation order.
- **M03-I05 · case-fact · F07:** Keyboard focus disappears after the shipping modal closes.
- **M03-I06 · case-fact · F08:** The error summary is not announced by the screen reader.
- **M03-I07 · case-fact · F09:** Refreshing after payment timeout can create a second pending order.
- **M03-I08 · case-fact · F10:** Duplicate requests share an idempotency key but receive different sandbox response identifiers.
- **M03-I09 · case-fact · F12:** The existing checkout-broken defect lacks reproducibility and expected-result evidence.
- **M03-B01 · case-brief · CB01:** Use CB01, the full versioned case brief printed once at the start of this packet, as a citable narrative source for details not normalized into F01–F12. Preserve its uncertainty language and do not treat narrative detail as approval, complete operational records, or professional judgment.
- **M03-S01 · assignment-scope · F03, F04, F05, F06, F07, F08, F09, F10, F12:** Build a starter version of “Six test-case designs, two evidence starters for the observed accessibility and duplicate-order issues, and result-pending fields for every unexecuted case.” from the listed case facts. Treat requested structures, controls, questions, calculations, and templates as learner-designed proposals. Where an operational record or result is absent, add a gap entry naming the missing evidence and authorized owner instead of fabricating it.

**Completion boundary**

Complete a bounded starter and gap analysis using only CB01, F03, F04, F05, F06, F07, F08, F09, F10, F12, and the assignment-scope record below. Populate supported fields, label every unavailable field “not supplied,” and cite the input ID for each material statement. You may design a proposed template, control, question, or decision rule, but must label it as a learner proposal rather than observed case evidence. Do not contact people, access live systems, run tests, sign records, claim approval, or invent names, dates, quotations, transactions, results, or source documents.

**Workbook plan:** M03-WP01 · 2026.09.01-workbook-plan-2

### Prerequisite check

- [ ] Confirm F03-F10 and F12; record that approved formula order, precise environments, complete steps, expected duplicate behavior, timestamps, screenshots/logs, and execution results are absent.
- [ ] STOP. If formula order, environment, reproducible steps, expected duplicate behavior, or evidence method is missing or conflicts with F03–F10/F12, route the design to authorized product, payments, accessibility, and QA reviewers; do not claim test approval, execution, pass/fail, or a defect conclusion.

### Operating procedure

1. Create exactly six stable test-case IDs spanning money boundary, calculation ambiguity, keyboard focus, screen-reader summary, timeout refresh, and idempotency.
2. Write preconditions and test data directly from supplied facts without inventing credentials or records.
3. Express each action sequence as a learner-proposed reproducible method.
4. State the expected result only where approved evidence exists; otherwise name the pending product decision.
5. Specify environment and evidence capture, marking absent versions, timestamps, logs, and screenshots not supplied.
6. Route requirement, accessibility, and payments questions to qualified reviewers before execution.
7. Final-QC IDs, sources, preconditions, steps, expected results, negative paths, and pending status.

### Field-by-field guidance — M03-A01

| Field | What high-quality completion requires |
|---|---|
| Test ID | Use one stable ID for each of the six designed cases. |
| Requirement/risk | Name the cited requirement, observation, or unresolved oracle addressed by the case. |
| Preconditions | State only supplied setup conditions; mark unavailable data Not supplied. |
| Test data | Use the exact supplied values or a clearly labeled learner-proposed safe value. |
| Ordered steps | Write reproducible numbered actions without claiming they were executed. |
| Expected result or decision gap | State the approved observable result or the precise missing decision that blocks it. |
| Environment | Name the supplied environment or Not supplied. |
| Evidence to capture | List the planned screenshots, logs, network records, accessibility tree, or identifiers; evidence remains pending. |
| Reviewer | Name the qualified product, engineering, accessibility, payments, or QA role. |
| Result | Use Not run or Blocked unless the packet supplies a result. |
| Status | Use Draft, Ready after approval, or Blocked. |

### Completed supported example — M03-A01

**Reference only.** This row demonstrates supported evidence and truthful status; it is not a learner submission or proof of live work.

| Test ID | Requirement/risk | Preconditions | Test data | Ordered steps | Expected result or decision gap | Environment | Evidence to capture | Reviewer | Result | Status |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| TEST-01 | Credit-decision arithmetic is disputed — M03-I03 (F05); approved order is absent — M03-I04 (F06). | Sample account has $10,000 limit and $9,600 open balance — M03-I01 (F03). | $700 item, ten-percent discount, $55 shipping, 8.25-percent tax rule — M03-I02 (F04). | 1) Load approved safe account; 2) enter supplied cart values; 3) submit only after the calculation rule is approved; 4) capture operands and decision trace. | Blocked — calculation order, rounding points, and expected credit decision are not supplied. | Not supplied | Calculation trace, displayed totals, decision message, request/response IDs, and timestamp. | Product owner, engineering owner, and QA lead | Not run | Draft — oracle decision pending |

### Completed known-gap example — M03-A01

**Reference only.** This row demonstrates how to preserve missing evidence without inventing a result.

| Test ID | Requirement/risk | Preconditions | Test data | Ordered steps | Expected result or decision gap | Environment | Evidence to capture | Reviewer | Result | Status |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| TEST-02 | Refresh after payment timeout can create a second pending order — M03-I07 (F09); duplicate requests share a key but sandbox IDs differ — M03-I08 (F10). | Approved safe payment sandbox account and timeout setup are not supplied. | Payment payload, idempotency-key generation rule, and expected record state are not supplied. | Learner-proposed sequence: submit, induce approved timeout, refresh once, and compare order/request records. | Expected duplicate-request and order-state behavior requires authorized product/payments decision. | Not supplied | Request IDs, key, response IDs, order IDs/statuses, timestamps, and logs. | Payments engineer, product owner, and QA lead | Not run | Blocked — safe setup and oracle not supplied |

### Supporting artifact build sequence

1. **M03-A02 · Accessibility evidence starter** — Produce a bounded, reviewable accessibility evidence starter from cited packet evidence while exposing unsupported fields and required approvals. Build 1 row from M03-I02, M03-I04 and address M03-EC02. Use only the scoped case-fact inputs below. Cite an input ID for each supported statement; label proposed structures “learner proposal” and unavailable evidence “not supplied.”
2. **M03-A03 · Duplicate-order evidence starter** — Produce a bounded, reviewable duplicate-order evidence starter from cited packet evidence while exposing unsupported fields and required approvals. Build 1 row from M03-I03, M03-I07, M03-I08 and address M03-EC03. Use only the scoped case-fact inputs below. Cite an input ID for each supported statement; label proposed structures “learner proposal” and unavailable evidence “not supplied.”

### Completed supporting-artifact examples

#### M03-A02 · Accessibility evidence starter

**Reference-only completed row.** Use it to understand the evidence boundary; do not present it as your own completed work.

**Criterion demonstrated:** M03-EC02

**Why this row is included:** The canonical workbook maps M03-EC02 to M03-A02. The row uses only the supplied numeric operands and known idempotency/response-identifier facts, preserves the undefined calculation order as a gap, and claims no test result.

| Record ID | Supported facts | Source input ID | Decision or action pending | Owner or reviewer | Evidence needed | Status |
| --- | --- | --- | --- | --- | --- | --- |
| CALC-TRACE-01 | The sample account has a $10,000 limit and $9,600 open balance; the cart has a $700 item, 10-percent discount, $55 shipping, and an 8.25-percent tax rule. The calculation order is disputed and undefined. Duplicate requests share an idempotency key while sandbox response identifiers differ. | M03-I01 (F03), M03-I02 (F04), M03-I03 (F05), M03-I04 (F06), and M03-I08 (F10) | Approve the calculation sequence, rounding points, expected credit decision, and request-identifier correlation rule before executing or grading the case. | Product owner, finance/payments owner, engineering owner, and QA reviewer | Approved requirement; safe environment; calculation trace; request, response, idempotency, order, and timestamp identifiers; and authorized expected-result oracle. | Design only — calculation oracle and execution evidence not supplied |

### Stop / Go / Escalate

| Decision | Rule |
|---|---|
| **Stop** | Stop execution or defect conclusions when expected behavior, environment, safe test data, or evidence method is missing. |
| **Go** | Proceed when all six designs are reproducible and unresolved expected outcomes are explicitly assigned. |
| **Escalate** | Escalate formula and duplicate-state ambiguity to product/payments; accessibility expectations to the accessibility owner. |

### Completion test

- [ ] Exactly six distinct risk-based designs are present.
- [ ] Each case has traceable data, method, expected-state boundary, reviewer, and evidence plan.
- [ ] No execution result is implied.

### Artifact map

- **M03-A01 · Six test-case designs:** Produce a bounded, reviewable six test-case designs from cited packet evidence while exposing unsupported fields and required approvals. Expected rows: 6. Criteria: M03-EC01. Scoped inputs: M03-I01, M03-I05, M03-I06, M03-I09, M03-I02, M03-I03, M03-I04, M03-I07, M03-I08.
- **M03-A02 · Accessibility evidence starter:** Produce a bounded, reviewable accessibility evidence starter from cited packet evidence while exposing unsupported fields and required approvals. Expected rows: 1. Criteria: M03-EC02. Scoped inputs: M03-I02, M03-I04.
- **M03-A03 · Duplicate-order evidence starter:** Produce a bounded, reviewable duplicate-order evidence starter from cited packet evidence while exposing unsupported fields and required approvals. Expected rows: 1. Criteria: M03-EC03. Scoped inputs: M03-I03, M03-I07, M03-I08.

### Evidence criteria

- **M03-EC01:** Each design states source, precondition, data, steps, expected result, environment, and evidence to capture without inventing actual results or timestamps
- **M03-EC02:** Uses supplied calculation inputs and known request-identifier facts only where available
- **M03-EC03:** Uses accessible names and defines observable assistive-technology outcomes while leaving execution pending

### Module 4 — Explore bounded edge cases

**Task mode:** bounded-case-starter

Charter an authorized exploration of retries, boundaries, navigation, interruption, and recovery.

**Deliverable:** A sixty-minute exploratory charter, pre-session coverage map, note template, and new-risk hypothesis list; no exploratory session or finding is represented as completed.

**Provided inputs**

- **M04-I01 · case-fact · F03:** The sample account has a $10,000 limit and a $9,600 open balance.
- **M04-I02 · case-fact · F04:** The cart includes a $700 item, ten-percent discount, $55 shipping, and 8.25-percent tax rule.
- **M04-I03 · case-fact · F05:** Product and development owners disagree about the credit-check calculation order.
- **M04-I04 · case-fact · F06:** The approved requirement does not define the calculation order.
- **M04-I05 · case-fact · F07:** Keyboard focus disappears after the shipping modal closes.
- **M04-I06 · case-fact · F08:** The error summary is not announced by the screen reader.
- **M04-I07 · case-fact · F09:** Refreshing after payment timeout can create a second pending order.
- **M04-I08 · case-fact · F10:** Duplicate requests share an idempotency key but receive different sandbox response identifiers.
- **M04-B01 · case-brief · CB01:** Use CB01, the full versioned case brief printed once at the start of this packet, as a citable narrative source for details not normalized into F01–F12. Preserve its uncertainty language and do not treat narrative detail as approval, complete operational records, or professional judgment.
- **M04-S01 · assignment-scope · F03, F04, F05, F06, F07, F08, F09, F10:** Build a starter version of “A sixty-minute exploratory charter, pre-session coverage map, note template, and new-risk hypothesis list; no exploratory session or finding is represented as completed.” from the listed case facts. Treat requested structures, controls, questions, calculations, and templates as learner-designed proposals. Where an operational record or result is absent, add a gap entry naming the missing evidence and authorized owner instead of fabricating it.

**Completion boundary**

Complete a bounded starter and gap analysis using only CB01, F03, F04, F05, F06, F07, F08, F09, F10, and the assignment-scope record below. Populate supported fields, label every unavailable field “not supplied,” and cite the input ID for each material statement. You may design a proposed template, control, question, or decision rule, but must label it as a learner proposal rather than observed case evidence. Do not contact people, access live systems, run tests, sign records, claim approval, or invent names, dates, quotations, transactions, results, or source documents.

**Workbook plan:** M04-WP01 · 2026.09.01-workbook-plan-2

### Prerequisite check

- [ ] Confirm F03-F10; record that session duration, tester, approved oracle, browser/device allocation, data-reset method, log access, and actual observations beyond the supplied facts are absent.
- [ ] STOP. If the session scope, tester, oracle, environment allocation, data reset, or log access is missing or conflicts across F03–F10, route the charter to the authorized QA, product, and accessibility reviewers; do not claim charter approval, execute exploration, or report a finding or severity.

### Operating procedure

1. State one bounded mission around checkout money, accessibility, and duplicate-order risk.
2. List supplied starting observations separately from learner-designed hypotheses.
3. Choose tours for boundary arithmetic, modal focus, announced errors, timeout refresh, and repeated idempotency.
4. Define what to vary and what to hold constant for each tour.
5. Specify notes, timestamps, screenshots, accessibility output, request IDs, and state transitions to capture.
6. Add pause and escalation rules for unsafe payment behavior, sensitive data, environment drift, and ambiguous requirements.
7. Final-QC mission, scope, exclusions, timebox, oracle gaps, evidence plan, owner, and unexecuted status.

### Field-by-field guidance — M04-A01

| Field | What high-quality completion requires |
|---|---|
| Section | Name the brief section or decision topic this row resolves. Module use: Use the charter to explore bounded checkout risks without substituting exploration for approved requirements or reproducible evidence. |
| Supported statement | Write a bounded statement supported by cited packet facts. Module use: Use the charter to explore bounded checkout risks without substituting exploration for approved requirements or reproducible evidence. |
| Source input ID | Cite the exact Fxx or module input ID supporting the entry. Module use: Use the charter to explore bounded checkout risks without substituting exploration for approved requirements or reproducible evidence. |
| Assumption or gap | Separate a provisional assumption from evidence that is absent. Module use: Use the charter to explore bounded checkout risks without substituting exploration for approved requirements or reproducible evidence. |
| Decision requested | Frame the exact approval, clarification, or risk decision needed. Module use: Use the charter to explore bounded checkout risks without substituting exploration for approved requirements or reproducible evidence. |
| Reviewer | Name the qualified review role and leave approval pending. Module use: Use the charter to explore bounded checkout risks without substituting exploration for approved requirements or reproducible evidence. |
| Status | Use a truthful state such as draft, open—not supplied, review pending, or blocked. Module use: Use the charter to explore bounded checkout risks without substituting exploration for approved requirements or reproducible evidence. |

### Completed supported example — M04-A01

**Reference only.** This row demonstrates supported evidence and truthful status; it is not a learner submission or proof of live work.

| Section | Supported statement | Source input ID | Assumption or gap | Decision requested | Reviewer | Status |
| --- | --- | --- | --- | --- | --- | --- |
| Mission and risk focus | Explore how build 4.8.17 handles money boundaries, focus/announcement, timeout refresh, and repeated idempotency using safe staging data. | F03, F07, F08, F09, F10 | Exact timebox, environments, safe account, and approved expected results are not supplied. | Approve charter scope and evidence method before a session. | QA lead with product, payments, and accessibility reviewers | Draft - session not run |

### Completed known-gap example — M04-A01

**Reference only.** This row demonstrates how to preserve missing evidence without inventing a result.

| Section | Supported statement | Source input ID | Assumption or gap | Decision requested | Reviewer | Status |
| --- | --- | --- | --- | --- | --- | --- |
| Oracle and stopping conditions | Product/development disagree and the requirement does not define calculation order. | F05, F06 | A pass oracle cannot be created for the credit calculation. | Obtain an authorized product/finance decision; explore only observable differences meanwhile. | Product and finance/payments owners | Blocked for pass/fail conclusion |

### Supporting artifact build sequence

1. **M04-A02 · Pre-session coverage map** — Produce a bounded, reviewable pre-session coverage map from cited packet evidence while exposing unsupported fields and required approvals. Build 2 rows from M04-I02 and address M04-EC02. Use only the scoped case-fact inputs below. Cite an input ID for each supported statement; label proposed structures “learner proposal” and unavailable evidence “not supplied.”
2. **M04-A03 · Exploratory note template** — Produce a bounded, reviewable exploratory note template from cited packet evidence while exposing unsupported fields and required approvals. Build 2 rows from M04-I03 and address M04-EC03. Use only the scoped case-fact inputs below. Cite an input ID for each supported statement; label proposed structures “learner proposal” and unavailable evidence “not supplied.”
3. **M04-A04 · New-risk hypothesis list** — Produce a bounded, reviewable new-risk hypothesis list from cited packet evidence while exposing unsupported fields and required approvals. Build 2 rows from M04-I04 and address M04-EC04. Use only the scoped case-fact inputs below. Cite an input ID for each supported statement; label proposed structures “learner proposal” and unavailable evidence “not supplied.”

### Completed supporting-artifact examples

#### M04-A02 · Pre-session coverage map

**Reference-only completed row.** Use it to understand the evidence boundary; do not present it as your own completed work.

**Criterion demonstrated:** M04-EC02

**Why this row is included:** The canonical M04-A02 route maps M04-EC02. The row specifies purposeful boundary and transition coverage instead of random clicking while leaving the session and observed results unclaimed.

| Element | From or trigger | To or outcome | Evidence and source ID | Owner | Open question | Status |
| --- | --- | --- | --- | --- | --- | --- |
| Boundary-value and state-transition coverage path | Account and cart values around the credit limit, followed by payment submission, timeout, refresh, and repeated idempotent request states. | Learner-proposed coverage: exercise below/equal/above decision boundaries and trace idle to submitted to timed-out to refreshed states while checking for one logical order. | M04-I01 (F03), M04-I02 (F04), M04-I07 (F09), and M04-I08 (F10) | QA lead with product, payments, and engineering reviewers | Approved calculation order, rounding points, expected state transitions, safe account, timeout method, and test environment are not supplied. | Learner-proposed coverage — exploratory session not run |

### Stop / Go / Escalate

| Decision | Rule |
|---|---|
| **Stop** | Pause for unsafe payment side effects, sensitive data, environment drift, or an absent oracle required for a conclusion. |
| **Go** | Proceed only with approved safe data, bounded scope, evidence capture, and explicit unknowns. |
| **Escalate** | Escalate new severe risks immediately and requirement ambiguity before assigning severity or pass/fail. |

### Completion test

- [ ] Mission, tours, variables, evidence, timebox gap, and stop conditions are explicit.
- [ ] Known observations are separated from hypotheses.
- [ ] No exploratory session or finding is fabricated.

### Artifact map

- **M04-A01 · Exploratory test charter:** Produce a bounded, reviewable exploratory test charter from cited packet evidence while exposing unsupported fields and required approvals. Expected rows: 12. Criteria: M04-EC01. Scoped inputs: M04-I01, M04-I05, M04-I06, M04-I07, M04-I08, M04-I02, M04-I03, M04-I04.
- **M04-A02 · Pre-session coverage map:** Produce a bounded, reviewable pre-session coverage map from cited packet evidence while exposing unsupported fields and required approvals. Expected rows: 2. Criteria: M04-EC02. Scoped inputs: M04-I02.
- **M04-A03 · Exploratory note template:** Produce a bounded, reviewable exploratory note template from cited packet evidence while exposing unsupported fields and required approvals. Expected rows: 2. Criteria: M04-EC03. Scoped inputs: M04-I03.
- **M04-A04 · New-risk hypothesis list:** Produce a bounded, reviewable new-risk hypothesis list from cited packet evidence while exposing unsupported fields and required approvals. Expected rows: 2. Criteria: M04-EC04. Scoped inputs: M04-I04.

### Evidence criteria

- **M04-EC01:** Defines mission, techniques, time, prohibited actions, and evidence
- **M04-EC02:** Exercises boundary values and state transitions rather than random clicking
- **M04-EC03:** Stops and escalates any security or production-impact question outside authorization
- **M04-EC04:** Cites the supplied input IDs for material statements and marks omitted operational records or results “not supplied” rather than fabricating them

### Module 5 — Make defects actionable

**Task mode:** bounded-case-starter

Rewrite and classify the known failures using impact and reproducibility evidence.

**Deliverable:** Two defect-report starters for the observed accessibility and duplicate-order issues, one incomplete-evidence remediation record for F12, and a severity-versus-priority decision proposal.

**Provided inputs**

- **M05-I01 · case-fact · F07:** Keyboard focus disappears after the shipping modal closes.
- **M05-I02 · case-fact · F08:** The error summary is not announced by the screen reader.
- **M05-I03 · case-fact · F09:** Refreshing after payment timeout can create a second pending order.
- **M05-I04 · case-fact · F10:** Duplicate requests share an idempotency key but receive different sandbox response identifiers.
- **M05-I05 · case-fact · F12:** The existing checkout-broken defect lacks reproducibility and expected-result evidence.
- **M05-B01 · case-brief · CB01:** Use CB01, the full versioned case brief printed once at the start of this packet, as a citable narrative source for details not normalized into F01–F12. Preserve its uncertainty language and do not treat narrative detail as approval, complete operational records, or professional judgment.
- **M05-S01 · assignment-scope · F07, F08, F09, F10, F12:** Build a starter version of “Two defect-report starters for the observed accessibility and duplicate-order issues, one incomplete-evidence remediation record for F12, and a severity-versus-priority decision proposal.” from the listed case facts. Treat requested structures, controls, questions, calculations, and templates as learner-designed proposals. Where an operational record or result is absent, add a gap entry naming the missing evidence and authorized owner instead of fabricating it.

**Completion boundary**

Complete a bounded starter and gap analysis using only CB01, F07, F08, F09, F10, F12, and the assignment-scope record below. Populate supported fields, label every unavailable field “not supplied,” and cite the input ID for each material statement. You may design a proposed template, control, question, or decision rule, but must label it as a learner proposal rather than observed case evidence. Do not contact people, access live systems, run tests, sign records, claim approval, or invent names, dates, quotations, transactions, results, or source documents.

**Workbook plan:** M05-WP01 · 2026.09.01-workbook-plan-2

### Prerequisite check

- [ ] Confirm F07 and F08; record that exact reproduction steps, environment, approved focus target, assistive-technology version, timestamps, screenshots, recordings, logs, severity, priority, and remediation decision are absent.
- [ ] STOP. If reproduction steps, environment, expected focus target, assistive-technology version, or supporting evidence is missing or conflicts with F07/F08, route the report to authorized accessibility, product, engineering, and QA owners; do not claim reproduction approval, execution, severity, priority, remediation, closure, or release impact.

### Operating procedure

1. Create a stable defect ID and concise observed-behavior title.
2. Record build and environment only if supplied; otherwise mark them not supplied.
3. Separate the disappearing-focus and unannounced-error observations into reproducible expected-versus-actual statements.
4. Draft minimal reproduction steps as a learner proposal and identify missing setup details.
5. Name accessibility evidence to capture without fabricating attachments.
6. Keep severity separate from priority and route both decisions to authorized roles.
7. Final-QC source IDs, reproducibility gaps, user impact boundary, evidence request, owner, and pending status.

### Field-by-field guidance — M05-A01

| Field | What high-quality completion requires |
|---|---|
| Defect ID | Assign a stable training defect ID. |
| Build/environment | Record exact supplied build/environment or Not supplied. |
| Preconditions | State the required starting UI/account state without inventing it. |
| Ordered steps | Write a bounded reproducibility sequence and keep execution pending. |
| Expected result | State an approved observable accessibility behavior or mark it Not supplied. |
| Actual supplied observation | Quote or paraphrase only the packet-supplied observation with source IDs. |
| User impact | Describe the bounded accessibility/business impact question; do not invent affected-user counts. |
| Evidence attachments/status | List required captures and mark them Not supplied or Pending. |
| Severity decision | Leave severity pending for authorized review unless the packet supplies a decision. |
| Priority decision | Leave priority pending and distinguish it from severity. |
| Owner | Name the accessibility, engineering, product, or QA role. |
| Status | Use Open, Blocked, or Draft; never claim reproduction or repair. |

### Completed supported example — M05-A01

**Reference only.** This row demonstrates supported evidence and truthful status; it is not a learner submission or proof of live work.

| Defect ID | Build/environment | Preconditions | Ordered steps | Expected result | Actual supplied observation | User impact | Evidence attachments/status | Severity decision | Priority decision | Owner | Status |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| A11Y-01 | Not supplied | Shipping modal is open; exact page/account state is not supplied. | Learner-proposed: navigate by keyboard, close the modal, inspect focus, then trigger the validation error and observe screen-reader announcement. | Approved focus-return target and error-summary announcement behavior are not supplied. | Focus disappears after modal close and the error summary is not announced — M05-I01 (F07); M05-I02 (F08). | Keyboard and screen-reader users may lose location or error context; affected-user count is not supplied. | Steps, browser/OS, assistive technology, recording, accessibility tree, and timestamp are pending. | Pending authorized accessibility review | Pending product/engineering triage | Accessibility reviewer and frontend engineering owner | Open — reproduction evidence pending |

### Completed known-gap example — M05-A01

**Reference only.** This row demonstrates how to preserve missing evidence without inventing a result.

| Defect ID | Build/environment | Preconditions | Ordered steps | Expected result | Actual supplied observation | User impact | Evidence attachments/status | Severity decision | Priority decision | Owner | Status |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| A11Y-GAP-02 | Not supplied | Existing checkout-broken defect record; reproducible setup is not supplied. | Not supplied | Not supplied | Existing defect lacks reproducibility and expected-result evidence — M05-I05 (F12). | Not supplied; must not be inferred from the defect title. | Safe account, environment, steps, expected target, capture files, and execution result are not supplied. | Blocked — evidence incomplete | Blocked — evidence incomplete | QA lead and accessibility reviewer | Blocked — setup and oracle not supplied |

### Supporting artifact build sequence

1. **M05-A02 · Duplicate-order defect-report starter** — Produce a bounded, reviewable duplicate-order defect-report starter from cited packet evidence while exposing unsupported fields and required approvals. Build 1 row from M05-I03, M05-I04 and address M05-EC01, M05-EC03. Use only the scoped case-fact inputs below. Cite an input ID for each supported statement; label proposed structures “learner proposal” and unavailable evidence “not supplied.”
2. **M05-A03 · Incomplete-evidence remediation record** — Produce a bounded, reviewable incomplete-evidence remediation record from cited packet evidence while exposing unsupported fields and required approvals. Build 1 row from M05-I05 and address M05-EC02. Use only the scoped case-fact inputs below. Cite an input ID for each supported statement; label proposed structures “learner proposal” and unavailable evidence “not supplied.”
3. **M05-A04 · Severity-versus-priority decision** — Produce a bounded, reviewable severity-versus-priority decision from cited packet evidence while exposing unsupported fields and required approvals. Build 1 row from M05-I03 and address M05-EC01. Use only the scoped case-fact inputs below. Cite an input ID for each supported statement; label proposed structures “learner proposal” and unavailable evidence “not supplied.”

### Completed supporting-artifact examples

No additional completed supporting-artifact row is supplied. Use the supporting artifact instructions, scoped inputs, completion checks, and known-gap method above; keep unsupported cells marked **not supplied**.

### Stop / Go / Escalate

| Decision | Rule |
|---|---|
| **Stop** | Stop closure, severity, priority, or release claims when reproducibility, expected behavior, or accessibility evidence is absent. |
| **Go** | Proceed to qualified review when the report separates observed facts, proposed steps, expected-state gap, and requested evidence. |
| **Escalate** | Escalate keyboard and screen-reader barriers to accessibility and product owners; release impact remains their decision. |

### Completion test

- [ ] Observed behavior, proposed reproduction, expected-state gap, impact boundary, and evidence request are distinct.
- [ ] F07 and F08 are both cited.
- [ ] No reproduction, severity, remediation, or closure is fabricated.

### Artifact map

- **M05-A01 · Accessibility defect-report starter:** Produce a bounded, reviewable accessibility defect-report starter from cited packet evidence while exposing unsupported fields and required approvals. Expected rows: 1. Criteria: M05-EC03. Scoped inputs: M05-I01, M05-I02.
- **M05-A02 · Duplicate-order defect-report starter:** Produce a bounded, reviewable duplicate-order defect-report starter from cited packet evidence while exposing unsupported fields and required approvals. Expected rows: 1. Criteria: M05-EC01, M05-EC03. Scoped inputs: M05-I03, M05-I04.
- **M05-A03 · Incomplete-evidence remediation record:** Produce a bounded, reviewable incomplete-evidence remediation record from cited packet evidence while exposing unsupported fields and required approvals. Expected rows: 1. Criteria: M05-EC02. Scoped inputs: M05-I05.
- **M05-A04 · Severity-versus-priority decision:** Produce a bounded, reviewable severity-versus-priority decision from cited packet evidence while exposing unsupported fields and required approvals. Expected rows: 1. Criteria: M05-EC01. Scoped inputs: M05-I03.

### Evidence criteria

- **M05-EC01:** Separates supplied user-impact evidence from the proposed repair order
- **M05-EC02:** Uses reliable reproduction only where the packet supports it and explicitly leaves F12 reproduction and expected-result evidence incomplete
- **M05-EC03:** Links the accessibility and duplicate-order observations to affected-user and business-impact questions without inventing test results

### Module 6 — Recommend release truthfully

**Task mode:** bounded-case-starter

Design focused regression and a conditional release-evidence process; do not run tests or record owner approval.

**Deliverable:** A regression manifest proposal, traceability matrix starter, accessibility-summary template, and conditional release-evidence brief with results and approval pending.

**Provided inputs**

- **M06-I01 · case-fact · F01:** The release candidate is build 4.8.17 in staging.
- **M06-I02 · case-fact · F02:** Six browsers and two mobile devices are in scope, while the plan covers one desktop browser.
- **M06-I03 · case-fact · F07:** Keyboard focus disappears after the shipping modal closes.
- **M06-I04 · case-fact · F08:** The error summary is not announced by the screen reader.
- **M06-I05 · case-fact · F09:** Refreshing after payment timeout can create a second pending order.
- **M06-I06 · case-fact · F11:** The tax service changed after the prior regression baseline.
- **M06-I07 · case-fact · F12:** The existing checkout-broken defect lacks reproducibility and expected-result evidence.
- **M06-B01 · case-brief · CB01:** Use CB01, the full versioned case brief printed once at the start of this packet, as a citable narrative source for details not normalized into F01–F12. Preserve its uncertainty language and do not treat narrative detail as approval, complete operational records, or professional judgment.
- **M06-S01 · assignment-scope · F01, F02, F07, F08, F09, F11, F12:** Build a starter version of “A regression manifest proposal, traceability matrix starter, accessibility-summary template, and conditional release-evidence brief with results and approval pending.” from the listed case facts. Treat requested structures, controls, questions, calculations, and templates as learner-designed proposals. Where an operational record or result is absent, add a gap entry naming the missing evidence and authorized owner instead of fabricating it.

**Completion boundary**

Complete a bounded starter and gap analysis using only CB01, F01, F02, F07, F08, F09, F11, F12, and the assignment-scope record below. Populate supported fields, label every unavailable field “not supplied,” and cite the input ID for each material statement. You may design a proposed template, control, question, or decision rule, but must label it as a learner proposal rather than observed case evidence. Do not contact people, access live systems, run tests, sign records, claim approval, or invent names, dates, quotations, transactions, results, or source documents.

**Workbook plan:** M06-WP01 · 2026.09.01-workbook-plan-2

### Prerequisite check

- [ ] Confirm F01, F02, F07-F09, F11, and F12; record that controlled test assets, requirement versions, environment details, accessibility evidence, tax baseline, defect links, execution records, and release authorization are absent.
- [ ] STOP. If controlled assets, versions, environments, accessibility evidence, tax baseline, defect links, or execution records are missing or conflict with F01/F02/F07–F09/F11/F12, route the manifest to authorized release, product, accessibility, payments, and dependency owners; do not claim regression execution, release recommendation approval, or authorization.

### Operating procedure

1. Index build 4.8.17 and every controlled requirement, test, environment, data, dependency, defect, and evidence item needed for regression.
2. Record source/location and version/date only when supplied; otherwise write not supplied.
3. Link the six-browser/two-device scope and accessibility checks to the relevant test assets.
4. Treat the tax-service change as a baseline invalidation requiring an approved new reference.
5. Include duplicate-order and incomplete-defect remediation artifacts without claiming closure.
6. Assign access/review owners and identify stale, missing, or blocked items.
7. Final-QC item uniqueness, version integrity, traceability, access status, gaps, and no release claim.

### Field-by-field guidance — M06-A01

| Field | What high-quality completion requires |
|---|---|
| Item | Use only a supplied value or a clearly labeled learner proposal; expose missing evidence. Module use: Use the manifest as the controlled index behind a conditional release recommendation, not as evidence that regression passed. |
| Source or location | Name the controlled source or mark its location not supplied. Module use: Use the manifest as the controlled index behind a conditional release recommendation, not as evidence that regression passed. |
| Version or date | Use supplied version/date only; otherwise mark not supplied. Module use: Use the manifest as the controlled index behind a conditional release recommendation, not as evidence that regression passed. |
| Owner | Name the authorized operating or specialist role. Module use: Use the manifest as the controlled index behind a conditional release recommendation, not as evidence that regression passed. |
| Access or review status | State whether review/access evidence is supplied, pending, or blocked. Module use: Use the manifest as the controlled index behind a conditional release recommendation, not as evidence that regression passed. |
| Gap | Name the missing artifact, result, version, or approval. Module use: Use the manifest as the controlled index behind a conditional release recommendation, not as evidence that regression passed. |

### Completed supported example — M06-A01

**Reference only.** This row demonstrates supported evidence and truthful status; it is not a learner submission or proof of live work.

| Item | Source or location | Version or date | Owner | Access or review status | Gap |
| --- | --- | --- | --- | --- | --- |
| Release candidate build | Staging build record; exact controlled location not supplied. | 4.8.17; date not supplied | QA/release owner | Build identity supplied; access and integrity review pending. | Commit/hash, deployment timestamp, configuration, and access evidence are not supplied. |

### Completed known-gap example — M06-A01

**Reference only.** This row demonstrates how to preserve missing evidence without inventing a result.

| Item | Source or location | Version or date | Owner | Access or review status | Gap |
| --- | --- | --- | --- | --- | --- |
| Accessibility regression evidence | Controlled location not supplied. | Date/version not supplied | Accessibility and QA reviewers | Blocked - review record absent. | F07/F08 observations require approved cases, environment coverage, capture files, and results; none are supplied. |

### Supporting artifact build sequence

1. **M06-A02 · Requirement traceability matrix** — Produce a bounded, reviewable requirement traceability matrix from cited packet evidence while exposing unsupported fields and required approvals. Build 2 rows from M06-I02 and address M06-EC02. Use only the scoped case-fact inputs below. Cite an input ID for each supported statement; label proposed structures “learner proposal” and unavailable evidence “not supplied.”
2. **M06-A03 · Accessibility summary** — Produce a bounded, reviewable accessibility summary from cited packet evidence while exposing unsupported fields and required approvals. Build 1 row from M06-I03, M06-I04 and address M06-EC03. Use only the scoped case-fact inputs below. Cite an input ID for each supported statement; label proposed structures “learner proposal” and unavailable evidence “not supplied.”
3. **M06-A04 · Conditional release-evidence brief** — Produce a bounded, reviewable conditional release-evidence brief from cited packet evidence while exposing unsupported fields and required approvals. Build 1 row from M06-I01 and address M06-EC04. Use only the scoped case-fact inputs below. Cite an input ID for each supported statement; label proposed structures “learner proposal” and unavailable evidence “not supplied.”

### Completed supporting-artifact examples

No additional completed supporting-artifact row is supplied. Use the supporting artifact instructions, scoped inputs, completion checks, and known-gap method above; keep unsupported cells marked **not supplied**.

### Stop / Go / Escalate

| Decision | Rule |
|---|---|
| **Stop** | Stop release recommendation when a critical manifest item, version, environment, dependency baseline, trace link, or result is missing or stale. |
| **Go** | Proceed to review when every required item is indexed, accessible to the authorized reviewer, and version-controlled. |
| **Escalate** | Escalate missing critical evidence and baseline drift to release, product, accessibility, payments, and dependency owners. |

### Completion test

- [ ] Build, requirements, cases, environments, data, dependency, defects, accessibility, and results are indexed.
- [ ] F01/F07/F08/F09/F11 drive explicit entries.
- [ ] The recommendation remains conditional and no regression result is invented.

### Artifact map

- **M06-A01 · Regression manifest:** Produce a bounded, reviewable regression manifest from cited packet evidence while exposing unsupported fields and required approvals. Expected rows: 22. Criteria: M06-EC01. Scoped inputs: M06-I02, M06-I05, M06-I06, M06-I07, M06-I01, M06-I03, M06-I04.
- **M06-A02 · Requirement traceability matrix:** Produce a bounded, reviewable requirement traceability matrix from cited packet evidence while exposing unsupported fields and required approvals. Expected rows: 2. Criteria: M06-EC02. Scoped inputs: M06-I02.
- **M06-A03 · Accessibility summary:** Produce a bounded, reviewable accessibility summary from cited packet evidence while exposing unsupported fields and required approvals. Expected rows: 1. Criteria: M06-EC03. Scoped inputs: M06-I03, M06-I04.
- **M06-A04 · Conditional release-evidence brief:** Produce a bounded, reviewable conditional release-evidence brief from cited packet evidence while exposing unsupported fields and required approvals. Expected rows: 1. Criteria: M06-EC04. Scoped inputs: M06-I01.

### Evidence criteria

- **M06-EC01:** Covers the changed dependency and critical checkout paths as planned scope
- **M06-EC02:** Discloses untested scope, unresolved barriers, and proposed exception fields without claiming acceptance
- **M06-EC03:** Avoids bug-free, fully accessible, secure, exhaustive, passed, or approved claims
- **M06-EC04:** Cites the supplied input IDs for material statements and marks omitted operational records or results “not supplied” rather than fabricating them

## Ambiguities to preserve

### Expected credit behavior is disputed and the approved requirement omits calculation order.

**Judgment required:** Pause the affected pass-fail decision and obtain an authorized product and finance clarification before codifying a test oracle.

**Do not assume:** Do not treat current implementation, developer preference, or product-owner expectation as the approved requirement.

### The duplicate order may involve application retry handling, the sandbox, or both.

**Judgment required:** Preserve identifiers and isolate components without claiming root cause prematurely.

**Do not assume:** Do not assign fault from timing correlation or one unsuccessful reproduction.

## Debrief guide

There is no universal release answer or complete test set. Strong QA states the tested scope, source of expected behavior, consequence of gaps, and authority for exceptions.

### Module 1

Missing expected behavior is a requirement defect, not a reason for QA to invent a rule. Risk ranking should emphasize user and business consequence, detectability, and reversibility.

**Strong evidence may include**

- Source-linked acceptance criteria
- Owner-assigned risk register

### Module 2

Environment diversity should follow the declared scope and risk. Versioning external services matters because a changed dependency can invalidate prior regression evidence.

**Strong evidence may include**

- Configuration and dependency matrix
- Repeatable synthetic test data

### Module 3

A screenshot alone cannot prove a result. Reproducible evidence connects approved expectations and exact conditions to observed behavior another reviewer can verify.

**Strong evidence may include**

- Complete test record
- Request, calculation, and accessibility evidence

### Module 4

Exploration is bounded investigation with a mission and evidence trail. It supplements repeatable tests while respecting authorization and production-safety boundaries.

**Strong evidence may include**

- Time-boxed charter and notes
- Coverage and newly discovered risk map

### Module 5

Duplicate orders can be high severity even when intermittent. Priority remains an authorized business decision, and every classification needs stated evidence and consequence.

**Strong evidence may include**

- Reproducible or occurrence-based defect evidence
- Severity and priority rationale

### Module 6

Marketing dates do not override release criteria. The recommendation should disclose barriers, scope, and exceptions so the authorized owner can make an informed decision.

**Strong evidence may include**

- Requirement-to-test traceability
- Signed exception and release record

## Specialist escalation boundaries

### Unclear financial calculation, tax treatment, contract pricing, or credit-policy requirement

**Route to:** Authorized product, finance, tax, legal, or accounting owner as applicable

**Learner boundary:** QA identifies ambiguity and tests approved behavior but does not make the policy decision.

### Security testing, payment handling, production data, accessibility conformance, or unresolved duplicate transaction risk

**Route to:** Authorized security, payment, accessibility, engineering, and release owners

**Learner boundary:** The learner remains within the approved environment and does not claim certification or security assurance.

## Use of the self-review rubric

Use the accompanying rubric to inspect the work, identify revisions, and prepare questions. It is formative guidance only—not a grade, verified completion, credential assessment, professional approval, or substitute for a qualified reviewer.