SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillscawplan-testpoint-generate

cawplan-testpoint-generate

Testing & quality

View repository

Updated 10-15 17:25

About this skill

CawPlan TestPoint Generate

Follow the user's primary languageGenerate copy; do not write the same passage once in Chinese and once in English.

Global visibility contract

Applies to all paths of this Skill and every tool call: the user does not need to pay attention to the internal execution process. Except for the final results explicitly specified by this Skill, information requiring SQA confirmation/supplementation, and next-step actions, remain silent.

  • Do not output progress announcements or process explanations before or after tool calls, including but not limited to: checking/fixing/retrying, JSON fields or file formats, status verification, background tasks, local Review service startup/restart/shutdown.Sole exceptionis the automatic callback of page Ask AI in §7.1: after confirming the task output event is optimize_requested , before any subsequent tool call, you must first output the specified "optimizing" notice once, to avoid Chat appearing unresponsive while generating the next Round.
  • Internally, you may verify and retry on your own; after success, directly output the user-visible result specified for that stage, without restating internal operations, command output, or retry counts.
  • Only when automatic recovery is impossible and SQA action is needed, briefly explain the user-perceivable blockage and the required action; do not expose internal implementation details.
  • The Human Input for HTML Review is collected internally by the CLI; for QA reporting, do not additionally echo, summarize, or concatenate page events in Chat or tool results. The testpoint-review show required by Optimize is not affected by this constraint.

Bootstrap

cawplan skill check

Workflow

Post-archive hot handoff of use cases (takes precedence over §1) — this item is for "generate test cases immediately" (or synonymous, see cawplan-testcase-generate P2), and the session already has a valid binding (product_id + requirement_id）？

  • Yes → read cawplan-testcase-generate skill, continue according to P2 hot handoff (stop the subsequent steps of this skill).
  • No → continue to §1 below.

1. Resolve target Requirement (entry priority)

On each generate test points request, resolve the target in this order (fall through until one row matches):

Step Condition Action
P1 This message has an explicit reference (Requirement link / display_id / requirement_id / switch to another Requirement) Cold handoff — rebind; ignore prior session binding
P2 Hot-handoff phrasing matches and session has valid binding (product_id + requirement_id both present) Hot handoff — use current session binding
P3 Session has a requirement draft (five-field draft from analysis) but no valid requirement_id (not saved yet) → Box 2 "Requirement not yet saved" below. Do not call APIs or show a test-point table
fallback None of the above (no link, no valid binding, no draft) → Box 1 "Lock Requirement" below

P2 wording (synonymous; a valid binding must be satisfied first before hot handoff)：马上生成测试点 / 生成测试点 / 补测试点 / 按上面那条 / 按上面那条生成测试点 / 接着刚才那条 etc.

valid binding = product_id and requirement_id both present in session. Phrasing alone without binding → fall through to P3 or fallback.

Box 1 · Lock Requirement (entry / fallback)

Trigger: the above table fallback(no Requirement link / no valid binding / no draft). P1 or valid P2 → do not pop up。

Prohibitedto include "use the one just archived" in the options (this belongs to valid P2 hot handoff and runs automatically).

Prefer AskUserQuestion（two options, each must have label + description; the tool will automatically append an Other free-input row,title/placeholder cannot be customized——Do notdefine or hand-write the Other / free-input row in the skill;follow the session languagechoose one of the two in the whole box, do not output both at the same time):

Field Chinese value English value
header Lock Requirement Lock Requirement
question Before generating test points, first determine which Requirement it is? Before generating test points, let's confirm which Requirement this is
option 1 · label Already has a link or ID I have a link or ID
option 1 · description Send me the Requirement link or REQ ID Send me the Requirement link or REQ ID
option 2 · label No Requirement No Requirement yet
option 2 · description Generate immediately and save to CawPlan Generate and save to CawPlan now

When AskUserQuestion is unavailable — plain-text fallback (verbatim;Follow the session languageChoose one of the two, do not output both):

锁定 Requirement
生成测试点前，先确定是哪条 Requirement？
1. 已有链接或编号 —— 选这个，把 Requirement 链接或 REQ 编号发我
2. 没有 Requirement —— 马上生成并保存到 CawPlan
请回复序号，或直接粘贴 Requirement 链接 / REQ 编号，或直接说你想怎么做。

Lock Requirement
Before generating test points, let's confirm which Requirement this is
1. I have a link or ID — pick this, then send me the Requirement link or REQ ID
2. No Requirement yet — generate and save to CawPlan now
Reply with a number, paste the Requirement link or REQ ID directly, or just tell me what you'd like to do.

Anchor：

  • Choose "existing link or ID" → ask the other party to send the Requirement link or REQ- ID(one sentence is enough); after obtaining the reference (in the next message, or paste it directly into the tool's automatic Other box) → parse according to the Requirement referencerules below; if only requirement_id is missing product_id → ask in plain language to supply product_id or the complete Requirement link. If it cannot be parsed → restate the two items and ask them to choose again or supply a valid reference.
  • Choose "no Requirement" → read the cawplan-requirement-analyze skill, follow cross-skill relay: the session writes resume_intent = testpoint; if there is a draft, skip analysis and go straight to the archive gate; if there is no draft, start from collecting materials.

Box 2 · requirement not yet saved

Trigger: in the table above, P3(has a requirement draft, no requirement_id). Valid hot handoff / Requirement link already given → do not show。

prefer AskUserQuestion（two options, each must have label + description; the Other row is automatically appended by the tool,do not define；Follow the session languagethe whole box is choose one of the two, do not output both):

Field Chinese value English value
header Requirement not yet saved Requirement Not Saved Yet
question This requirement has not yet been saved to CawPlan; save it first, then come back to generate test points This requirement hasn't been saved to CawPlan yet — save it first, then generate test points
option 1 · label Save now Save now
option 1 · description Save it and then continue generating test points Save it, then continue to generate test points
option 2 · label Do not save for now Not yet
option 2 · description Pause for now, I will take another look at this requirement Pause for now, I'll review this requirement again

When AskUserQuestion is unavailable — plain-text fallback (verbatim;Follow the session languagechoose one of the two, do not output both):

需求还没保存
这份需求还没保存到 CawPlan，先保存再来生成测试点
1. 马上保存 —— 存好再接着生成测试点
2. 先不保存 —— 先停一下，我再看看这份需求
请回复序号，或直接说你想怎么做。

Requirement Not Saved Yet
This requirement hasn't been saved to CawPlan yet — save it first, then generate test points
1. Save now — save it, then continue to generate test points
2. Not yet — pause for now, I'll review this requirement again
Reply with a number, or just tell me what you'd like to do.

Anchor：

  • "Save now" → read the cawplan-requirement-analyze skill, the session writes resume_intent = testpoint, follow the save/archive flow (the confirmation gate remains as usual）；SUCCESS ) then return to this skill's §2 refresh to continue.
  • "Do not save for now" → stop; keep the draft, do not generate test points.
  • If SQA uses the tool's automatic Other or replies freely → judge by content (change target / add clarification); if it cannot be understood, restate the two options.

Requirement reference

Parse in the following order:

  1. A valid product_id + requirement_id takes priority; bind directly, do not call the display-id query.
  2. For the old Portal URL, only parse the string, never request the page:

/product/{product_id}/qa-insights/test-suites/requirements/{requirement_id}

  1. A bare display_id must strictly be REQ- + digits (^REQ-\d+$); or use the Browse URL:

/browse/product/{product_key}/qa/requirement/{display_id}

For a bare display_id or Browse URL call (the complete URL needs shell quotes):

cawplan qa-insights requirements resolve '<display_id_or_browse_url>'
  • This command first locally validates/extracts display_id; if the format is wrong, do not request the API. The Browse URL's product_key(such as CP) is not product_id, and it must not be used to infer the UUID.
  • SUCCESS: complete the rebind only when meta.product_id and meta.requirement_id both exist, and data is usable Requirement data; record data as requirement_data, then enter the display-id fast-path of §2, and do not call requirements get。
  • FAILURE / validation: Prompt that display ID must be REQ- + number, do not continue to fetch TestPoints or create a Review.
  • FAILURE / not_found: Prompt that the Requirement does not exist, stop. Other FAILURE or UNKNOWN report truthfully, do not guess the ID, do not fall back to requirements get。
  • SUCCESS but is missing the two parsed IDs, or data is not a usable Requirement structure, treat as abnormal returned data, stop.

All URLs only parse the string; do not call cawplan api or HTTP on Portal/Browse pages. Only when requirement_id ask again for product_id or the full reference, do not scan the product.

Rebind only replace the entire context after the new target is fully parsed successfully (product_id、requirement_id, Requirement data, test-point stubs), and clear the old target's review_id、review_url and the Review page task handle; if parsing fails, do not clear the old binding or Review. At the same time bind only one Requirement; the same as the current binding requirement_id is treated as refreshing the same one, not as a rebind. If the message contradicts itself (for example, a new URL + "still the same one as before"), ask first, do not guess.

Cross-skill handoff

  • Outbound(box 1 "No Requirement", box 2 "Save now"): before handoff write resume_intent = testpoint。
  • Inbound return: after requirement analysis archives SUCCESS , the initiator continues from §2 refresh .
  • A1 §6 guided inbound: after the requirement analysis §6 success receipt, SQA says "generate test points now" → under a valid binding, P2 hot handoff, directly run §2 refresh (no need to paste the requirement again).
  • Outbound return (resume_intent = testcase）: after test points archive SUCCESS(or §10 count_matched confirms it has been stored) , if the session has resume_intent = testcase，read and clear resume_intent, read the cawplan-testcase-generate skill and continue from its §2 refresh ;do not append §9.5 test case guidance; do not stop in this skill waiting for the next instruction.
  • Post-archive test case guidance: at the end of the §9.5 success receipt, optionally append one sentence (see the guidance at the end of §9.5); if the user replies "generate test cases now" → read the cawplan-testcase-generate skill (P2 hot handoff); if they do not take it up, do not repeat the prompt.
  • Box 1 "existing link or number" parses successfully → continue with P1 cold handoff,do not pop upbox 2.

2. Refresh before generate

Silently obtain the latest Requirement data for this time, and uniformly record it as requirement_data：

  • successfully executed this time requirements resolve: directly use that command's data; it and requirements get return the same five-field Requirement structure. This time requirements get。
  • valid product_id + requirement_id, old Portal URL, hot handoff, or A1 archive return: execute:
cawplan qa-insights requirements get <product_id> <requirement_id>

After obtaining requirement_data through the above two paths, both must execute:

cawplan qa-insights testpoints list <product_id> <requirement_id>

data.test_points.length is the already-archived count N used by §3's incremental gate and §6's incremental-scope closure. This skill no longer tracks it as a reconcile baseline — testpoint-review start (§7.1) records it into the Review State's own count_before at creation time, and the page advances it after every successful Save to CawPlan; the count-reconcile flow now runs entirely page-side (§10), so Chat has no write_outcome/count_before state of its own to maintain.

Result Action
Requirement data source SUCCESS Use latest five fields from requirement_data silently; do not diff against chat cache
Requirement missing (404 or explicit not-found) Report "this Requirement no longer exists" / "This Requirement no longer exists" (follow the session languagechoose one of the two); do not generate from stale context
Requirement data abnormal / FAILURE / UNKNOWN report truthfully and stop; do not fetch TestPoints, do not create a Review, and do not use old data
TestPoints FAILURE / UNKNOWN report truthfully and stop; do not create a Review

Use five fields for generation only. Do not track module_tree_node_id, review_status, or ticket_id for A2 logic.

display-id fast-path only eliminates duplicate GETs adjacent to the resolver within the same request; it does not establish a cross-turn cache. Subsequent new supplementary generation turns, hot handoff, or A1 archive regression still execute requirements get, then refresh TestPoints.

3. Incremental gate (§9.3)

Check in this order (library-empty check first — do not evaluate intent wording before this):

  1. testpoints is empty → generate directly. Do not ask, regardless of how vague the phrasing is (e.g. "生成测试点" alone). This is the most common case (first-time generation) and must never fall into step 2.
  2. testpoints is non-empty and intent is vague ("生成测试点" only, no indication of supplement vs. review) → stop and ask:
    • Supplement a few more on top of existing?
    • Show what's already archived first?
  3. testpoints is non-empty and intent is clear ("再补两条并发的" / "看看已有的") → proceed directly.

4. Read coverage references (required)

Before discovering obligations, use the file-reading tool to read both files completely; do not rely on memory or hardcoded rules in this skill. Do not enter Step 1 until both reads have returned successfully. If either file cannot be read, stop and report the missing reference instead of generating a draft.

  • references/coverage-dimensions.md — discovery knowledge used in Steps 1–2.
  • references/review-checklist.md — terminal checklist applied only in Step 5; reading it here does not make it a second generator.

After both reads succeed, go straight to Step 5. Do not call any tool and do not pause for confirmation between finishing these reads and starting Step 5 — in particular, do not call AskUserQuestion here; there is nothing to ask at this point.

5. Generate test points (no write)

Target order: coverage completeness first (Recall > Precision); it is allowed to generate more directional test points that can be deleted, butred line 0 always takes priority. First fully expand the candidates, then uniformly triage and converge; do not pick "representative scenarios" during the discovery phase.

Below, "candidate" refers to what coverage-dimensions.md calls an obligation: the smallest verification obligation that must be explicitly covered or have its disposition explained. Candidates are first listed independently one by one, and each is judged for whether it ultimately goes into a test point or remains in doubt; there is no need to build a separate status table, ledger field, or coverage matrix — source judgments are made on the fly, no table is built, and nothing is presented or persisted.

Step 1 — Discovery

  1. Read the five fieldssentence by sentence in full to the end, and split out mutually independent verification candidates by object, operation, relation, constraint, change, and invariant; even if several items have already been found, you must not wrap up early.
  2. For each matched value, state, condition, source, role, applicable level, before/after change, and unaffected object, discover candidates separately. If multiple partitions may have different results, list them separately first and do not merge them first — whether they belong to the same verification target and whether they should be merged into one row is a Step 4 judgment; this step only expands and does not converge, and you must not prematurely summarize candidates across partitions or objects in one sentence just because "they will be merged in the end anyway." Exclusion/scope-declaration sentences must be expanded separately: when a sentence of the kind "count only X, do not merge with Y" or "does not include / does not affect / is independent of / is unrelated to ..." appears in the five fields,having no explicit action and merely drawing a boundary around some concept or removing ambiguity,you must not skip it just because it reads like background explanation or a definition — you must produce a separate candidate verifying that "this scope/boundary is indeed respected in actual behavior" (for example, "changes in the number of connections on other types of ports should not affect the image upper-limit judgment").
  3. For each item, use the path types of references/coverage-dimensions.md and the A→B→C→D→E change axis asdiscovery prompts(Group E is read item by item only when its enabling conditions are met). The C/D eight axes must be read item by item; do not stop early just because the requirement has no keywords; whether there is positive exclusion evidence is judged uniformly in Step 3.
  4. As long as the basic direction matches the feature form, it enters the candidates: the normal main path; exceptions in external input; legal boundaries when a range exists; and the reverse direction when cancellation/undo/rollback exists. The requirement not spelling out failure details does not mean they do not apply.
  5. If the five fieldscannot form an operation + directional expectation at all, stop and ask SQA to supplement; if thin but testable, continue, and the gaps go into doubt.

Discovery completion criteria (before entering Step 2): The five fields explicitly indicate that every input, configuration, or parameter that affects a certain final deliverable has separately formed a candidate for "whether this factor correctly acts on that deliverable"; verification of the final deliverable must not be replaced by the parameter having been selected, saved, UI-linked, or other intermediate results. If the core result or behavior is produced by AI / model capability, judgment has been completed according to the coverage-dimensions.md E-group enabling conditions and each axis has been checked, and a candidate has been formed for every applicable E axis. If there are still clear influencing factors or applicable E axes without candidates, Step 1 is not complete.

Script after stopping(plain text, verbatim;follow the conversation languagechoose one of the two, do not output both):

This requirement doesn't have enough detail to generate test points yet (missing the operation or expected direction) — please add what it does and what's expected, and I'll continue.

Step 2 — Fill in relationship partitions and meaningful combinations

  1. If the requirement has genuine relationship semantics, fill in partition candidates according to the relationship knowledge in coverage-dimensions.md ; do not cover only the one-sided relationship given in the requirement (quantity comparisons usually check < / = / >, and the specific expectation is still routed by evidence in Step 3).
  2. After two factors are combined, as long as they may changeusability, result, state, side effects, feedback, scope of impact, or recovery behavior, expand combination candidates; by default, check only binary combinations, and expand to ternary combinations only when the requirement explicitly involves three-factor interaction, or when no binary check can express the risk.
  3. Meaningless full Cartesian products are prohibited; factors that only "appear at the same time" but do not change behavior are not combined. When unsure whether behavior is affected, keep the combination candidate for Step 3 to route, and do not silently discard it.

Step 3 — Route each item by evidence

Each candidate ultimately and can only be classified into one of the following categories:

  • Test point: The direction is unique, and "operation/condition + directional expectation" can be written without fabricating details. If only "whether to include it in this round" has not been decided, but the functional form clearly applies, also generate a directional test point and add "(scope to be confirmed)" at the end of the title.
  • Uncertain: Multiple reasonable implementations or expectations exist; necessary trigger conditions are missing; or an assertion can be made only after specific rules are supplemented. Format: 〔what it points to〕+〔why it is uncertain〕+〔suggested action〕.
  • Excluded: Limited to the five fields explicitly listing it as out_of_scope, the functional form directly and positively proving it impossible, or a type/state/business constraint clearly making it unreachable; record a brief reason. "The requirement did not mention it," "it feels unimportant," or "there is already a similar point" must not be used as reasons for exclusion.

C/D asymmetry hard rule: For the eight axes 幂等 / 并发 / 一致性 / 存量兼容 / 环境兼容 / 性能 / 安全审计 / 可观测 apply the positive-form threshold of coverage-dimensions.md item by item. Only when the threshold positively proves inapplicability may the axis be excluded; otherwise that axis must contribute at least one "test point" or "uncertain." When multiple axes point to the same gap, the uncertain wording may be merged, but the axis names or destinations must not be omitted as a result. If the functional form of A/B axes clearly does not involve them, no candidates may be produced.

Red line 0 — Anti-fabrication (highest priority)：

  • Titles may use only the specific facts already present in the five fields, as well as directional expectations such as "should succeed / should fail / should be intercepted / should have clear feedback."
  • When the five fields are not provided, it is forbidden to fabricate specific values, thresholds, counts, timeout durations, copy, error codes, hidden product rules, or implementation methods.
  • If a candidate has only specific parts lacking evidence, prioritize splitting it into "directional test points + specific details in doubt"; do not discard the entire testable direction just because the details are unknown.
  • Values, enums, copy, or rules already given in the five fields may be used directly.
  • Recall-first only allows addingdirections with evidence, and does not allow adding fabricated details.

Discipline for items in doubt：

  • "Not mentioned in the material / needs supplementing" cannot by itself constitute a doubt; you must point out the specific coverage direction, the missing decision, and the recommended action.
  • Multiple reasonable implementations (such as hiding the entry point or intercepting after click) must be flagged as in doubt; do not guess one of them.
  • Product-specific interactions, hidden rules, cross-feature ownership, and subjective experience can only serve as capability-boundary hints and must not pretend to be covered.

Step 4 — Unified convergence after all routing

Only after all candidates have completed Step 3 is it allowed to generate final titles, merge, and deduplicate within the batch. **Using representative scenarios to replace candidates is forbidden.** The quantity is determined by the coverage space, with no fixed upper or lower limit.

Granularity and merge rules：

  1. One line = one verification goal (what is being tested); do not write preconditions + step sequence + per-value Expected; executable scripts belong to A3. The granularity of candidates may be finer than the final Test Point—merging multiple candidates expanded in Step 1 into one line is a normal output of this step, not a failure of the discovery phase.
  2. Merge criteria (first judge the nature of the difference, then judge whether it is the same behavior)：
    • Whether the difference between two candidatesonlycomes from partition values under the same verification goal (specific objects/positions such as first/middle/last, comparison-relation values < / = / >, boundary values, input values, state values, and when the package/permission/state itself is a partition that the goal is meant to cover, for example "the free version/paid version perform the same operation, and the results should remain consistent")?
      • operation type(delete/add/replace/submit...) is the same, and only thetarget objectdiffers (which position/which item it acts on) → this is a partition.
      • Whether a precondition can be incorporated into a partition depends on whether it introduces a different product behavior or rule: if it is merely consistency verification of the same behavior's result under different preconditions, the precondition is a partition; if the precondition changes the product behavior being verified itself (for example, the paid version unlocks a feature branch that the free version does not have at all), then it is not.
      • As long as any difference does not satisfy "only from partition values" (different operation type, different attribute/behavior being verified, precondition introduces new product behavior) → must not be merged, and one must not redefine "this also counts as a partition" just to force a merge.
    • After confirming it is a partition-only difference, replace the specific values with placeholders and compare at the semantic level (not the string level): after removing the partition and normalizing the wording, is it still verifyingthe same product behavior/attribute on the same object? If yes, merge; if after normalization the object or behavior is actually different, revert to not merging.
    • Do not first assume "the final result should be merged into one row" and then work backward to package different verification objectives into partitions of the same goal; the nature of the difference must be determined first, and only then can it be decided whether to merge. The reverse is not allowed.
  3. Merge the same objective with only different test data into one row, and in the titlelist all key values/states/locations/conditions/sources/scopes; default items must not be omitted. Candidates of the scope/boundary declaration type are not merged by default: candidates produced by the Step 1 "exclusionary/scope declaration sentence" rule (such as "a certain type of statistical scope is not merged with other types") remain as separate rows by default, unless it can be clearly proven that the merged title still fully preserves the verification intent of that scope declaration. When in doubt, keep the item separate; do not force a merge for table conciseness or to make up the count and cause the verification intent of that scope declaration to disappear.
  4. Merge conservation: merging must not change the final classification; every test point candidate before merging must map to at least one final title, and its key partition must be traceable back from the title. If this cannot be done, do not merge (for detailed review, see §6 "Upper limit three directions + list all partition values" and references/review-checklist.md §3).
  5. Within-batch deduplication only handles drafts without ids in the current round. Archived rows must not be deleted by semantics; across batches, only id is used to distinguish them. Incremental presentation may prove coverage by the overall set of "existing N + newly added M", but archiving still only submits M.
  6. Fill in for each final test point group、tags、priority; the labeling rules are based on coverage-dimensions.md .

Title form: precondition + behavior under test + directional expectation; one title expresses only one verification objective.

Good: When the Free plan already has 50 workflows, Duplicate again should indicate that the limit is exceeded and cannot be copied

Good: After selecting each Duration option (5s/10s/15s, including the default 15s), the exported video duration should match the selected option

Bad: Test the copy function

Bad: Open configuration → select each option separately → export and check for each option (these are A3 steps)

Priority rules (required for each test point)：

Basis for judgment priority
Positive main path, or involves funds, permissions, or data loss risk HIGH (default level)
Exceptions / boundaries of core links MEDIUM
Non-core, auxiliary, UI details LOW
  • AI does not proactively generate CRITICAL; SQA may specify it during revision.
  • priority must be exactly, character for character, one of CRITICAL / HIGH / MEDIUM / LOW.
  • Uncertainty is not a test point and does not require priority.

6. Step 5 — Coverage closure and one requirement-specific reverse check

Execute once after Step 4 forms the draft and before the first presentation. If Step 1 determines that the five fields are completely untestable, skip.

Compare against the references/review-checklist.md that was fully read in §4, go through it from beginning to end(must not be skipped, and must not be replaced by memory): check item by item coverage closure (source / relationship partition / behavior combination / destination), convergence conservation (merge mapping, title traceability), red lines, and output contract; if a gap is found, add candidates and return to Step 3 for triage; if an incorrect merge is found, split it back into separate titles. The following five items are the most easily missed in this round and must be explicitly confirmed, and must not be skipped just because the checklist has already been completed:

  • Step 1 finds that the completion criteria still hold: Candidates have been formed for both the definitive influencing factors of the final product and the applicable axes of the enabled Group E; if this does not hold, add candidates and return to Step 3 for triage.
  • Each of the eight C/D axes has a destination: idempotency/concurrency/consistency/existing-data compatibility/environment compatibility/performance/security audit/observability, confirm axis by axis that each either has positive exclusion evidence or has been assigned to a test point or flagged as uncertain, leaving no empty axis.
  • Upper limit of three directions + all partition values listed: for candidates involving comparison or configuration/capacity switching,< / = / >(or smaller/unchanged/larger) whether all three states are present; whether the specific partition values already merged into the title (position, state, comparison result, etc.) are preserved verbatim, not blurred out by abstract words like "any/some/a certain kind of".
  • Red line 0 not crossed: all titles use only facts already present in the five fields and directional expectations; no fabricated values, counts, copy, or error codes.
  • Output contract: each test point has one objective, a valid primary label, a correct priority enum, English sessions use glossary terms, at most one supplementary label and only in tags[1].

After completionone requirement-specificity reverse check: set the checklist aside, reread the five-field source text and the draft side by side, and ask only "which risk specific to this requirement is this table most likely to have missed", scanning the remaining specificity statements to the end; newly discovered items go through Step 3 triage, then do one more source/destination/merge conservation confirmation, and there is no need to read through the entire checklist again.

Incremental scope: at closure, use "N archived + M newly added this round" to judge coverage as a whole; existing titles may carry candidates; generate M only for gaps, and never modify or reissue N. Execute only once before the first presentation of this round; do not automatically rerun after SQA revisions unless regeneration is explicitly requested.

Internal only, one version: candidates, exclusion reasons, inspection process, checklists, or source markers must not be output. After completing the five steps, produce only one version of the final list and hand it to §7 to create a Review; when newly added rows from this stage enter the Review, status is unchanged(not modified by SQA); at archiving, the corresponding is_edited: false（§9）。

7. Present to SQA

Output discipline: during presentation,do not lay out a test point table—the presentation, editing, deletion, and addition of test point content are all handled by the Review page (§7.1); Chat only provides "which requirement + summary + uncertainty list + how to open the page".Prohibitedrestating internal processes—words such as "axis traversal / self-check / coverage dimension checklist / completed according to... / five fields read / verification complete" must not appear. The first sentence goes directly to the point.

7.1 Create Review, obtain review_id(execute immediately after Step 5 is completed, earlier than any Chat output)

After Step 5 produces the final test point list,before outputting any content to Chatfirst create the Review:

  1. write the Review initial content as JSON, optionally carrying a five-field snapshot. The input contract is as follows:

    • newly added drafts this round：{title, group, tags, priority}; must not include id，archived omission (or be false）。
    • CawPlan archived test points(incremental scenarios only):{id, title, group, tags, priority, archived: true}；id must use the server-side original values returned by §2 refresh, and must not be rewritten or generated.
    • testpoint-review start only use the count of archived: true as the Review State's count_before; the input total is not the reconcile baseline. The page hides these archived rows, and Save to CawPlan always submits only unarchived drafts.
    • Pass the complete open-question list from §5 as a string array to --open-questions-file(pass an empty array when there are no open questions); the CLI assigns a stable ID to each question. Review State is the single source of truth for questions and HTML answers.

  2. Call:

    cawplan qa-insights testpoint-review start --product-id <id> --requirement-id <id> \
  --lang <会话语言 zh|en> --test-points-file <path> [--requirement-file <path>] \
  --open-questions-file <path>

    （--test-points/--requirement is the inline JSON version of the same shape; either one may be used.)

  3. The command returns {review_id, file, draft_count, archived_count, group_count, count_before, open_question_count}. Record review_id to the session binding (at the same level as product_id/requirement_id , see Session state); validate that open_question_count matches the passed-in list. Chat test point counts are read-only from draft_count/group_count; do not recount them from the input or the page.

  4. Use the Agent'smanaged background taskto start the page service (first get the URL, then wait according to platform capabilities):

    cawplan qa-insights testpoint-review open --review-id <id> --no-browser

    must use the Agent tool's managed background capability (e.g. Bash run_in_background: true); keep that task handle;it is forbiddento use nohup、&、disown or a terminal multiplexer to detach the service from the current Agent conversation. Read the Open this URL to review test points: <url>from the startup output, and record the complete review_url and the background task handle; continue Chat output as soon as the URL appears, and do not wait for the service to end before the URL appears. While the page service is still running, it is forbidden to start a second review_id for the same open。

    Route by the Agent's task-resumption capability (the page actions and subsequent business flow are exactly the same; only the waiting method changes)：

    • Claude: if the managed background task's completion notification automatically wakes the same conversation, keep the existing background notification logic; after outputting per §7.2, you may end the current response, and resume by recognizing the event when the task completion notification is received. Do not change to Codex's foreground attached waiting, and do not repeatedly start open。
    • Codex / ChatGPT: after the background command returns session_id , if the current turn ends, subsequent command completion events will only be written to the session log and will not automatically start a new model turn. Therefore, after obtaining the URL, you must send §7.2 (or the §8 output contract in a revision round) as a commentary / intermediate messageto SQA,must not send final, and must not end the current turn; then immediately use write_stdin with empty input (or the platform-equivalent session wait) to wait for the same session_id, waiting at most 60 seconds per wait. A single wait timeout only means there were no page events during that period,notan overall wait timeout; as long as the returned result still contains session_id, you must immediately and silently continue waiting. Neither the number of waits nor the cumulative duration may be used as a stop condition, and you must not instead send a final such as "currently waiting for your confirmation/edit" to wrap up. Stop waiting only when a valid page event is received, the task exits abnormally, or SQA explicitly cancels/switches the task. After the service exits, recognize the event within the current turn and resume. This rule applies to the first open, restoring the page, opening the next Round after optimization, and the save wait in §9; each open must retain and wait for its own session_id。

    After the background task ends, first identify the page action: both Ask AI and Save to CawPlan success close the same open background task; the task completion notification itself cannot distinguish between the two. After receiving the notification, extract only one line from the task output TESTPOINT_REVIEW_EVENT <event>: Claude reads from the output file (e.g. rg -o 'TESTPOINT_REVIEW_EVENT (optimize_requested|save_completed)' <output-file>), Codex reads from the final output of the same attached session mentioned above; do not guess actions based on a generic task-completion summary, and do not echo the archived response body from the task output into Chat.save_completed → go directly to the success receipt flow in §9; do not enter §8; event missing or invalid → read the latest Review State and then decide; do not guess.

    Automatic main flow of the page's Ask AI: after confirming the event is optimize_requested , you must first send 正在优化，请稍候… / Optimizing, please wait…(choose one according to the session language) as user-visible text to Chat, and this text must appear before the first tool call after event recognition; then read the latest Review State. The page click has already completed the lock,this entry skips §8 step 1; do not call request-optimize; if review_status is pending_optimize or optimizing, continue directly from §8 step 2. After completing apply-optimization , open the Review page for the next Round according to §8 step 5.

does not exist"first display in Chat, and only create review after SQA confirmation" this kind of intermediate state — as long as Step 5 is completed, the Review has already been created.

Incremental scenario(the library already has archived test points): first use the archived N items read by refresh according to §2 (retain the server-side id for each item and mark archived: true) + the M newly added this round (without id), and use them together as the input for --test-points-file to create. The creation result must satisfy archived_count = N、draft_count = M、count_before = N, and the pending-save set contains only M; if any condition is not met, stop, and do not open the page or submit. (Or continue using the same review_id, depending on whether it is a subsequent supplementary round of the same Review — the principle is consistent with §3 Incremental gate: continue the same Review data, and do not open a separate new Review for each incremental round.)

7.2 Chat presentation (summary + doubtful list, no table)

Opening（〔需求名〕 = summary → truncate function_description → requirement_id, consistent with the display-name rules in save confirmation and other places;N = testpoint-review start returned by draft_count，M = returned group_count，read only from command output; do not count lines yourself）：

  • First batch(library is empty, verbatim;follow the session languagechoose one, do not output both):

    Requirement "〔requirement name〕" has generated N test point drafts, grouped into M groups. For details and editing, open the Review page: Drafted N test points for requirement "〔requirement name〕" across M groups — open the Review page for details and editing:

  • Incremental(already in the library, verbatim;follow the session languagechoose one, do not output both):

    Requirement "〔requirement name〕" has N newly added test point drafts this round. For details and editing, open the Review page: Drafted N new test points for requirement "〔requirement name〕" this round — open the Review page for details and editing:

Immediately followed by one line with a clickable link (verbatim, fill in the complete review_url；follow the session languagechoose one, do not output both):

Review page:Click here to open Review page: Open it here

Broken-link recovery prompt(only on first presentation;follow the session languagechoose one, do not output both):

Note: This link is only valid during the current Claude run; the draft is saved automatically. After the link expires, just send "Restore Review page" and that's it. Note: This link is only available while the current Claude session is running. Your draft is saved automatically. If the link stops working, just send "Restore the Review page".

When SQA sends "Restore Review page" (or the corresponding English): use the current binding's review_id; if the page service has been shut down, according to the existing rules in this section, re-run testpoint-review open --review-id <id> --no-browserin the background once, then return only the new review_url. Do not create a new Review, regenerate test points, or overwrite the existing Review State.

Do not degrade to giving only commands or only review_id。 review_url is a local temporary address; while the page service is alive, reuse the same link. Only if the service has been shut down, restart it once in the background open --no-browser and replace it with the new URL; do not run two identical Review services at the same time. Ordinary Review has no fixed duration expiry; the 10-minute threshold is only used to identify optimization requests that have not been called back for a long time after clicking Ask AI, and to prompt SQA to manually continue optimization.

ThenOpen Questions List(§5): from the latest Review State's open_questions read the full text item by item and display 〔what it points to〕+〔why it is doubtful〕+〔suggested action〕; no coverage checkbox matrix; if there are no open questions, explicitly state "no open questions"/"no open questions". Chat must retain the complete display, and it can still be viewed when HTML is unavailable; the sole source of truth for questions is the Review State, and no separate copy is stored in the session.

The Review page displays below Overall Feedback Questions to Confirm: when there are open questions, it is collapsed by default, and the top only shows the total number of questions; after expanding, the answer input box is always editable, and about 650ms after you stop typing, it is silently auto-saved; on blur, it saves immediately, and no submit button or answer status label is shown. When there are more than 4 items, the area scrolls internally; when there are no open questions, the entire Questions area is hidden. Clearing the input box persists the answer as null; on success there is no prompt, and on failure the input is retained and a retryable error is shown. When the page is hidden / left, it submits the latest input as much as possible; before clicking Ask AI to Optimize or Save to CawPlan, unsaved answers must first be successfully flushed, otherwise the corresponding operation is blocked. Answers are persisted with the Review State and remain after restoring the page; unanswered questions do not block Save.

Tail(after the Open Questions List,present only the first timeoutput verbatim; revision rounds switch to the concise output contract in §8;do not use a modal；follow the session languagechoose one, do not output both):

If you have changes, you can say them directly here, or go to the Review page to edit them; once you confirm everything is fine, please click Save to CawPlan on the Review page to complete the submission. Tell me your changes here, or edit them directly on the Review page; once it looks good, click Save to CawPlan on the Review page to submit.

Do not state draft totals beyond N/M above — except for this opening sentence, which uses the N/M reported by the command return value, other occasions (re-display after revision, progress reminders, etc.) no longer repeatedly report the number, to avoid conflicting with the discipline that "N/M only comes from command output" and being misused as a count of items.

8. Revise from SQA feedback

Review State（review_id corresponding persisted data) is the sole source of truth for test points. Both Chat and the Review page are input entry points, but neither maintains its own copy of test point data in the session—before any round of processing, first read the latest Review State, and do not assume that what Chat remembers is consistent with the page's current state (the page may already have Edit/Delete/Add done directly by QA).

First triage by entry point, then execute the numbered steps below:

  • Chat revision feedback → Starting from step 1, Chat proactively locks Review.
  • §7.1 Page Ask AI automatic callback → The page has already locked Review; skip step 1, execute step 2 directly; even if later reading pending_optimize or optimizing, do not additionally call request-optimize。
  • 继续优化 Review 页面 / Continue optimization fallback → Per this section's Fallback trigger, execute step 2 first; continue from step 3 only if the State still needs optimization, and likewise do not call request-optimize。

Any form of revision feedback in Chat follows the same single path, without distinguishing "reply with doubts" / "natural-language overall revision" (e.g., "add boundary scenarios exceeding the limit") / seemingly mechanical single-item operations (e.g., "delete item 3")—all are treated as a new round of AI input for the current Review, and do not open a separate "direct editing, no Round consumed" fast track:

Whether Optimize is triggered by the page or by Chat, the shared locking boundary projects the current Round's already-saved Edit / Add / Delete / Comment / Overall Feedback / HTML Answer Question together into the existing Human Input outbox. HTML answers are recorded as [Answer Question] to record the question and the current final non-empty answer; before the boundary, no matter how many times it is autosaved, only the last value is collected; answers cleared to null are not collected. Chat source text continues to be collected only by the transcript, does not enter this projector, and is not specially deduplicated against HTML answers.

  1. Call cawplan qa-insights testpoint-review request-optimize --review-id <id> to lock the current Review (the effect is equivalent to clicking "Ask AI to Optimize" on the page: the whole page is locked,review_status becomes pending_optimize, but the page does not need to be open).

  2. Read the latest Review State (page edits, deletions, additions, and comments are all based on this):

    cawplan qa-insights testpoint-review show --review-id <id>

    Use the complete output State (especially test_points[].current、status、comments、global_comments、open_questions and its HTML answer and requirement) as the only page input for this round of AI reasoning; do not use only old test points or doubtful content in Chat.

  3. Give "latest Review State + this round's Chat input" to AI reasoning, producing the next Round's modifications/additions and the complete active doubt set. Answers to doubts in Chat are only this round's natural-language input and do not write to or overwrite the HTML answer in Review State; if they conflict with the HTML answer, the AI understands them together in this round, with no CLI conflict detection or cross-entry deduplication. Before writing apply-optimization , the output JSON mustbe in the following shape (each modified and added must provide the complete title / group / tags / priority）：

    {
  "modified": [
    {
      "id": "tp_001",
      "fields": {
        "title": "...",
        "group": "...",
        "tags": ["..."],
        "priority": "HIGH"
      }
    }
  ],
  "added": [
    {
      "title": "...",
      "group": "...",
      "tags": ["..."],
      "priority": "HIGH"
    }
  ],
  "questions": {
    "retained_ids": ["oq_001"],
    "added": ["〔恢复〕失败恢复方向仍未明确；建议确认是否允许重试。"]
  }
}

    Review State in current is only a current snapshot,not modified an output field of ; nor can title / group / tags / priority be flattened onto modified entries, but must be placed in fields。questions to fully determine the next Round:retained_ids retain existing questions and HTML answers, remove those not listed,added create new questions without answers; no longer separately judge "whether truly resolved".

  4. Call apply-optimization to persist; the command must use --output-file：

    cawplan qa-insights testpoint-review apply-optimization --review-id <id> --output-file <absolute-json-path>

    This command isatomic: if any test point or questions output is invalid, it will explicitly report the field path, and will not apply any entries, update doubts, clear comments, change status, or advance the Round; at this point keep the original pending_optimize, correctthe same JSON and directly retry apply-optimizationand must not call again request-optimize. Only after all validations pass, write test points and remaining doubts at once, increment round by 1, and restore the page to editable.

Fallback trigger: when SQA sends in Claude Chat 继续优化 Review 页面 or Continue optimization , first execute step 2 of this section's show, then reason based on that State; if it is in pending_optimize or optimizing, continue directly from step 3 of this section, and must not call again request-optimize。恢复 Review 页面 Still only reopen the page according to the recovery rules in §7; even if the page is pending, do not automatically advance optimization under that trigger word. 5. Confirm whether the current page service is still alive: if alive, reuse review_url(the service will reread the latest Round from Review State); if closed, rerun in the background once open --no-browser and record the new URL. It is forbidden to run two identical Review services at the same time. 6. apply-optimization After success, reread the latest Review State; the Chat's complete remaining doubts list only takes its open_questions. Do not manually maintain remove / keep / add rules again in the session, and do not rewrite the AI-returned results based on answer sufficiency.

Revised Chat output contract

After a successful revision, output in the following order, and keep only these three blocks in the body; wording may be expressed naturally,exact copying of the examples is not required：

  1. Latest Review link: each round must provide once, and only once, a clickable review_url. Do not provide only the command or review_id; no need to write the Round number or page-existing information such as "Round updated".
  2. Complete remaining doubts list: output item by item the complete content of open_questions ; do not merely say "N items remain", and do not list only topics/axis names. If there are no remaining doubts, clearly state that there are no remaining doubts.
  3. Brief guidance: only express "if there are changes, continue in Chat or go edit on the page; if there are no problems, click Save to CawPlan on the page". The wording may be adjusted naturally, not fixed, and do not repeat the link, Round, number of test points, or number of remaining doubts.

No extra success summary: do not restate or rewrite apply-optimization 's success output; do not output "applied N items", "currently N items total", "round N", or "0 skipped", and do not relist in Chat the test points added/modified in this round—details are carried by the Review page. A validation failure will not produce a new Review result; the same JSON must be corrected according to the atomic operation rules above and retried; a successful result's skipped_count must be 0, and remain silent.

Structure example (only to illustrate structure and information, not fixed wording):

Review 页面：[打开最新版本](<review_url>)

存疑清单：
1. 〔指向哪〕为什么疑；建议动作。
2. 〔指向哪〕为什么疑；建议动作。

有修改可以继续说，或直接在 Review 页面编辑；没问题就在页面点击 Save to CawPlan。

Ambiguous edits → ask, and do not guess the specific referent.

SQA insists on keeping two similar rows → keep both; this is an explicit instruction when handing off to AI reasoning, and when AI processes the next Round it should not re-merge these two.

Never auto-save / auto-submit. Revisions in Chat only advance the Round and do not trigger archiving; approval such as "looks good" ≠ saving to CawPlan (for the archiving path, see §9).

9. Archive (write — page-only, Chat never calls testpoints archive directly)

Archiving has only one entry point: the HTML Review page. When SQA says in Chat 保存 / 存 / 入库 / 保存到 CawPlan / 确认提交,do notpop up a confirmation box in Chat or directly call the archive command:

  1. If the page service already started in §7 is still alive, reuse that background task and review_url，must not start a second open。
  2. If the service is closed, rerun in the background once cawplan qa-insights testpoint-review open --review-id <id> --no-browser, and get the new URL.
  3. Output a clickable link, and wait for the current open background task to end; after SQA successfully clicks Save to CawPlan on the page, the page will close the Server, and the waiting Agent can then continue to output the success receipt.

Guidance text (verbatim, fill in the complete review_url；follow the session languagechoose one of the two, do not output both):

Review page:Click here to open. Please click Save to CawPlan to complete the submission. Review page: Open it here. Click Save to CawPlan to submit.

This ensures that the logic for archived status, excluding deleted, interception of unprocessed feedback, duplicate submission protection, etc. always exists in only one place (page side /api/save-to-cawplan), and does not produce two archiving paths, Chat / page.

Save preconditions: if the page still has any test point Comment, Overall Feedback, or newly added/modified non-empty Questions to Confirm answers in this Round, and they have not yet been consumed by a successful Ask AI optimization, Save to CawPlan must reject the submission and prompt to Ask AI first; there is no confirmation popup or forced submission entry. Only Edit / Delete / Add (without the above unprocessed human input) can be saved directly according to the current page state.

When Save is clicked on the page, it will first flush the not-yet-saved Questions answers, and then execute the above precondition check. Unanswered questions, answers cleared to null and answers already consumed by the previous round of AI and become the current round_answer_baseline do not block Save; non-empty answers different from the baseline must first Ask AI. An intercepted Save does not trigger Human Input collection; on a successful Optimize, the final non-empty answers in this Round in the HTML that differ from the baseline are collected by the existing Human Input projector/outbox, and answers cleared to null skip Human Input.

The success receipt is triggered automatically and does not require SQA to report back: after SQA successfully clicks Save to CawPlan on the page, the page will close the local Server; the Agent's previously pending open call then ends. According to §7.1, after confirming from the task output file that the event is save_completed , read the final Review State once, obtain the number of newly added archived: true entries in this round,automaticallyoutput the success receipt in Chat (§9.5 format, with both the verbatim text and the append conditions kept unchanged); it is forbidden to output "optimizing", call request-optimize or enter §8, and SQA does not need to return to Chat to say "saved" again.

Only prerequisite (⚠️ requires the same conversation): the page service must be started in the background by the current Agent conversation and retain the task handle, so that during archiving it can wait for it to end and automatically send the receipt. SQA does not need to, and should not, manually run openin the terminal again. If the conversation is switched to a new one midway, the new conversation does not have the old background task handle; it should first confirm that the old service has stopped, then start it once more and return a new link.

Success receipt (§9.5) — only place SQA sees a count. Two lines when the latest requirement_data.redirect_url is present; otherwise line 1 only. Use N = the number of newly added archived: true entries in this round's Review State(read from the final Review State after a successful page Save, do not count the lines yourself).〔需求名〕 = summary → truncate function_description → requirement_id.

  • Line 1(verbatim;follow the session languagechoose one of the two):已保存 N 条测试点到需求「〔需求名〕」下。 / Saved N test points under requirement "〔需求名〕."
  • Line 2(only when the latest requirement_data.redirect_url is non-empty;on a separate line, not attached to the end of line 1; verbatim;follow the session languagechoose one of the two):Requirement 链接:{当前环境 Portal Host + redirect_url} / Requirement link: {current environment Portal Host + redirect_url}

The Requirement link is generated only in the final display layer of this receipt: silently execute cawplan config env, read its Portal value as the current environment Host, remove the trailing / from Host and concatenate with redirect_url . Do not use or fall back to url; do not modify requirement_data, Requirement queries, or ID resolution.If redirect_url is missing or null — output line 1 only; say nothing about links or the missing field.

Forbidden in success receipt: per-row tables; title lists; id lists; re-generated or summarized titles; any line about missing redirect_url; apology or post-hoc recount explanations。

§9.5 trailing guidance (optional append; preserve verbatim along with the append conditions) — whenallconditions are met, in the success receiptat the endappend verbatim on a new line (no popup, no follow-up questions,only once this turn；follow the session languagechoose one, do not output both):

Want to generate test cases next? Say "generate test cases now" and I'll do it right in this session. Want to generate test cases next? Say "generate test cases now" and I'll do it right in this session.

Append conditions(must all be met):

  • This turn's Save to CawPlan result is success (the page returns archived_count > 0 and not NOOP/failure)
  • sessionhas no resume_intent(not an automatic outbound regression after a cross-skill inbound handoff)
  • not a save failure / conflict (409) path

do not append：NOOP(no content to submit), the page returns 409/502 failure; outbound resume_intent = testcase automatically flows back to cawplan-testcase-generate(already automatically resumed, no further guidance needed). SQA does not follow up and goes off to do something else → let it be, do not repeat the prompt。

User follows up: SQA says "generate test cases now" → use the session product_id + requirement_id to read the cawplan-testcase-generate skill, in the current session P2 hot-handoff directly run §2 refresh,no needto paste the requirement or test points again.

On failure/conflict(the page returns 409 unhandled feedback, 409 full-page lock, 502 archive failure): truthfully report the error message returned by the page, guide SQA back to the page to handle it (e.g., first resolve unresolved comments, or retry later), do not pretend success, do not retry on SQA's behalf.

10. UNKNOWN write outcome

This step now runs page-side, not in Chat. The /api/save-to-cawplan route (triggered by the page's Save to CawPlan button) calls testpoints archive; if that returns outcome: UNKNOWN (transport failure / post-write 5xx, result indeterminate), the page itself runs the count-reconcile (testpoints reconcile with the Review's tracked baseline) and branches on reconcile.decision — count_matched marks the batch archived without re-submitting, retry_same_batch/count_unexpected report a failure without silently re-archiving. Chat never sees UNKNOWN directly and never calls testpoints reconcile itself; it only reports whatever the page's final result was (§9's failure branch) or posts the success receipt (§9.5) when the page succeeded.

11. Archived row edits

SQA wants to change/delete a row with id → direct them to Test Suites UI. A2 only appends; no PATCH/DELETE.

Session state (in-conversation only)

Binding: product_id, requirement_id, review_id, review_url, Review page background task handle/liveness status, requirement_data the five-field snapshot in,summary and url。display_id are not required state for subsequent flows.

Open questions: do not maintain a second list in session state. Activity doubts and the final HTML answer are both persisted in Review State; Chat's first display and each revision display read from that State. Chat answers are kept only as the current turn's natural language input and are not written back as question answers.

The test point content itself is not maintained in this session state——Review State（review_id the corresponding persisted data) is the single source of truth (§8). This session state only records "which Requirement / which Review is currently being dealt with"; it does not record draft content, who changed which line,is_edited etc.—these are read from Review State or computed by the page/apply-optimization , and are not maintained a second time in the Chat session.

This is a genuine deletion relative to v1, not a streamlined description: v1 used to maintain three groups of state—"① Binding / ② Work set (original draft snapshot, touched-row markers, current draft, archive stub) / ③ Write (pending_write、write_outcome)"—because Chat itself directly presented tables, received revisions, and invoked archiving, it needed to compute is_editeditself and track the original draft itself.This mechanism is entirely retired after the page integration：presentation is delegated to the page (§7.1), revisions uniformly go through Review State + apply-optimization(§8), archiving is only triggered on the page,is_edited is calculated by the page according to status !== "unchanged" (no longer inferred by Chat), and the archiving result is synchronously sent back by the page (§9); Chat no longer needs its own write state machine.

Before refreshing the binding, first confirm that review_id still points to the same Review; Rebind (P1 cold handoff switch Requirement) clears all bindings, including review_id—switching to a new Requirement is considered starting a new Review.

Walkthrough example (workflow Duplicate — requirement 019fb63e-d5ad-7cb7-8b5f-761ceeb50c0a)

Five fields (excerpt)：workflow project Duplicate; entry is the project card more menu; normal expectation is to generate a copy, make it visible in the list, and open it in a new window; constraints include workflow type only, shared items from others cannot be copied, naming Copy of xxx, 125-character upper limit, materials copied together, Free plan upper limit of 50, etc.

obligation discovery (excerpt)：owned by self / shared by others, workflow / other types, successful copying, naming and materials preserved, 50-item quantity boundary, 125-character length boundary, idempotency of consecutive triggers, visibility in the list after writing, etc. first each enter the same checklist; the 50-item quota and concurrent operations may change the result, so combined obligations are retained. If the remaining C/D axes are not positively excluded by the form threshold, they are all classified as test points or open questions, and no independent axis-judgment table is maintained.

Intra-batch deduplication example：there is already “When a Free plan reaches 50 workflows, Duplicate should prompt that the limit is exceeded” → do not separately generate “The 51st click on Duplicate should still prompt that the limit is exceeded” (same verification objective, only different state).

Sample test points (draft)：

1. Copying and naming

No. Title Label Priority
1.1 After clicking Duplicate on a workflow project owned by the user, a copy named “Copy of original project name” should appear in the list 正向 HIGH
1.2 When a Free plan account already has 50 workflows, clicking Duplicate again should prompt that the maximum limit is exceeded and cannot copy 边界 MEDIUM
1.3 Clicking Duplicate rapidly in succession should create only one copy 幂等 HIGH
1.4 While Duplicate is in progress, there should be an in-progress state, and the entry should not be triggerable again before completion 交互反馈 LOW

Open questions (excerpt; different gaps are not merged)：

  1. The constraints do not clarify whether AD Video / Story types hide the Duplicate entry—it is recommended to state this in requirement out_of_scope or confirm that it is sufficient for the UI-layer entry to be invisible.
  2. 〔Concurrency × 50-item upper limit〕Concurrent Duplicate may change quota judgment and creation results, but the requirement does not give concurrency expectations—it is recommended to confirm whether this is included, and add whether it should be blocked or allow partial success.
  3. 〔Existing-data compatibility〕This changes existing workflow capabilities, but the behavior for old projects or historical data is not clarified—it is recommended to confirm the compatibility scope of this change.
  4. 〔Environment compatibility〕The feature is initiated via the Web client, but the feedback and recovery direction after network interruption are not clarified—it is recommended to confirm whether weak network / interruption recovery is covered.

The remaining C/D obligations that are not positively excluded by the form threshold must also each have a test point or open-question destination; this section only shows the title format and does not mean they have been silently excluded.

Walkthrough example (login — baseline vs redline 0)

Five fields (excerpt)：account + password login; entry is the login page; normal expectation is successful login and entering the home page; constraints do not specify an account lockout policy.

Generation (draft)：

1. Login verification

No. Title Label Priority
1.1 Logging in with the correct account and password should succeed and enter the expected page 正向 HIGH
1.2 Logging in with an incorrect account or password should fail and give a clear prompt 异常 MEDIUM

Uncertain (optional, one item): Whether consecutive login failures trigger account lockout — the five fields do not state a policy; please confirm whether this is within the current scope.

Do not generate: test points requiring a specific number of attempts/wording, such as "lock the account after the 3rd failure" or "the prompt should be 'Incorrect username or password'" (Redline 0).

Walkthrough example (video config — granularity / Duration merge)

Five fields (excerpt): before exporting, the Duration option 5s / 10s / 15s (default 15s) and Resolution can be set in the video configuration panel; the normal expectation is that the exported video duration matches the selected Duration; the constraints do not state whether 4K requires a paid plan.

Granularity: three Duration options → list all values in one item, do not split into three items, do not stuff in steps — see §5 Step 4 and the Good/Bad examples. If the five fields state "4K is available only with a paid plan" → 4K and ordinary resolutions havedifferent preconditions/expectations → make it a separate item or put it in Uncertain.

Sample test points (draft, excerpt)：

1. Export and duration

No. Title Label Priority
1.1 After selecting each Duration option (5s/10s/15s, including the default 15s), the exported video duration should match the selected option 正向 HIGH

Rules Index

Authoritative rules live in Workflow; this section is navigation only. On conflict: Redline 0 > Recall priority > convergence rules.

Rule Authority
Redline 0 — anti-fabrication §5 Step 3 Redline 0 + §6 output contract check
Obligation discovery §5 Step 1–2; knowledge → references/coverage-dimensions.md
Disposition / C-D asymmetry §5 Step 3
Granularity + merge conservation §5 Step 4; recheck → §6
Priority — each test point must have CRITICAL/HIGH/MEDIUM/LOW §5 Priority rules
Uncertain list — format, session state, and complete output for each round §5 Uncertain list discipline; first presentation → §7.2; revision → §8 step 6 + output contract
Double closure + requirement-specific review §6 Step 5; output checks → references/review-checklist.md
Review creation + Chat presentation — no tables; summary + uncertain list + clickable page link for each round §7
Draft totals — N/M comes only from the testpoint-review start return value; do not count rows yourself §7.2
Revision (Chat or page) — all go through Review State: lock → AI → next Round; Chat only outputs the link + all remaining uncertain items + brief guidance §8
Archive / confirm / receipt §9 (page-triggered; Chat only reports results); UNKNOWN reconcile handled on the page side → §10
Batch-internal dedup §5 Step 4 (cross-Round id uniqueness is guaranteed by Review State's next_seq , not maintained in Chat session state)
API Generation-time read → `cawplan qa-insights requirements resolve
Trigger boundary §1 decision tree P3 → box 2; fallback → box 1; ticket URL without test-point intent → not this skill
Failures §9 failure/conflict branch; Review State is retained, drafts are not lost

Output & Confirmation

  • Generate + create Review + Chat presentation (do not archive) → §5–§7
  • Chat revision → §8 (lock → AI → next Round; do not directly modify test point content in Chat)
  • Archive → §9 (only the page Save to CawPlan, Chat only guides + reports receipt); UNKNOWN reconcile handled on the page side → §10

References

  • references/CAWPLAN_OPEN_API.md
  • references/coverage-dimensions.md
  • references/review-checklist.md