Use AI to build a feasible plan: budget, capacity and test findings

1. 1

   Give AI decision material, not just a feature wish list

   Two weeks before a release, support wants bulk editing, product wants first-use guidance and sales wants enterprise login. Asking AI simply to “prioritize” may produce a convincing scorecard. If the customer counts or benefits behind those scores were never supplied, the table is tidier but the evidence is no stronger. This lesson makes the assistant use the budget, effort estimates and dependencies you actually provide.

   The workflow to understand is: Collect requirements and constraints → define comparison criteria → request alternatives and evidence → check feasibility → reconsider priorities when validation changes. First learn why each input and constraint matters, then study the requests, finished examples and explanations. This is a reading lesson about external AI tools; no account or runtime is required.

   The fictional release must include A, improved search for existing users. B, C and D are optional. A mandatory condition is different from a highly scored preference. If the model imagines enough revenue from SSO to remove A, it has changed the assignment. State the boundary explicitly before asking it to compare options.

   AI’s contribution is to make comparison work inspectable: classify requests, add effort for candidate bundles, flag violated limits and summarize what changed. The person remains responsible for checking arithmetic and identifying claims that exceed the research. A recommendation such as A+B is less useful than a record of the conditions under which that recommendation is feasible.

   The following three replies are from one actual Claude Sonnet 5.5 conversation. It first considers A+B, revises to A+C2 after a keyboard-use finding and finally retains only A after engineering capacity falls. These are condition changes, not deliberately manufactured bad replies. Every effort estimate, cost and test count is fictional material for learning the workflow.

2. 2

   Define units and dependencies before comparing numbers

   G2 supplies twelve engineering person-days, four design person-days and two QA person-days. A person-day measures effort, not elapsed calendar time. Four engineering person-days do not automatically mean four calendar days or two days with twice as many people. QA is verification work. In this case roles cannot substitute for each other, so spare engineering does not resolve a QA shortage.

   

   Feature estimates are A: 4/1/1, B: 5/1/1, C: 3/2/1 and D: 8/1/2, in engineering/design/QA order. Their totals are six, seven, six and eleven person-days. At the invented uniform rate of KRW 200,000, A costs KRW 1.2m. The KRW 3.6m budget could cover eighteen person-days in aggregate, but every role-specific limit must also hold. An affordable total can still contain impossible staffing.

   B depends on completed A; C is independent. An A+B recommendation therefore needs a sequence as well as a sum. A+C may permit parallel work, but actual people and availability have not been provided. The prompt asks for sequence without committed dates, keeping an effort comparison separate from a delivery promise. AI cannot infer a reliable calendar from three capacity totals alone.

   The demand signals also use different units. Thirty-two support tickets include repeated users. Twenty incomplete setups are sessions out of fifty, not twenty distinct people. One prospect’s SSO question establishes no contract value. Putting all three into one customer-count column would collapse different meanings. The downloadable pack preserves G, F and S IDs so constraints and evidence can be inspected independently.

   Initial effort for the AI comparison — fictional values

   Feature	Engineering	Design	QA	Dependency
   A quick search	4	1	1	Mandatory
   B bulk editing	5	1	1	After completed A
   C first-use guidance	3	2	1	Independent
   D enterprise SSO	8	1	2	Supplier timing unknown
   Available	12	4	2	No role substitution

   Download the complete material

1. 3

   First request: name the options and rejection rules

   The first prompt names four bundles: A+B, A+C, A+B+C and A+D. These are concrete options a team might discuss, rather than an exhaustive combinatorial search. Request the same columns for each: engineering, design, QA, total effort, cost and feasibility. “Reject any exceeded limit” is a more useful instruction here than “score the ideas,” because attractive features must first fit available resources.

   Claude calculates A+B as 9/2/2, thirteen person-days and KRW 2.6m; A+C as 7/3/2, twelve person-days and KRW 2.4m. The editor independently adds the feature estimates and confirms both fit. A+B+C requires nineteen person-days, KRW 3.8m and three QA days, violating both budget and QA capacity. Checking the output beside the feature-level inputs exposes mistakes a tidy total would conceal.

   A+D is the more revealing case: seventeen person-days and KRW 3.4m fit the budget, while three QA days exceed the available two. The recorded answer rejects it. If an assistant passed it based on cost alone, a targeted follow-up would ask it to recompare the QA column with G2. That mistake did not occur in this run; keep the correct intermediate values as the baseline for the next change.

   The reply prefers A+B, but it has not demonstrated an improvement in customer outcomes. It uses the support signal and dependency as reasons for a draft choice. A+C remains feasible. A person must judge those reasons and ensure ticket counts are not converted into users or time savings. Retaining the alternative is useful when later evidence changes the initially preferred option.

   This is a fictional teaching case. Analyze only this text, without outside sources, files or tools.
   Turn the material into an AI planning review. Separate requirements, preferences and unknown evidence by ID. Calculate engineering/design/QA effort, total effort, cost and feasibility for A+B, A+C, A+B+C and A+D. Respect dependencies and role-specific limits. Compare two feasible options and recommend a draft without turning repeated tickets or small samples into measured benefits. State sequence and scheduling questions rather than firm dates.
   
   Fictional practice project. People, effort, costs and observations are invented. A person-day is one person's work for a day, not one calendar day. Amounts are KRW.
   G1 | Aim to release a small bundle in two weeks. A, improved search for existing users, is mandatory. The target is not a delivery commitment.
   G2 | Available capacity: engineering 12 person-days, design 4, QA 2. Roles cannot substitute for one another. All three limits must hold.
   G3 | Practice cost is 200,000 per person-day for every role; budget ceiling 3,600,000. No other costs. Cost equals total person-days times the rate.
   F-A | Quick search: engineering 4, design 1, QA 1. No dependency; mandatory under G1.
   F-B | Bulk editing: engineering 5, design 1, QA 1. A must finish first.
   F-C | First-use guidance: engineering 3, design 2, QA 1. Independent of A/B; effort is an unvalidated estimate.
   F-D | Enterprise SSO: engineering 8, design 1, QA 2. Independent feature; external supplier timing is unknown.
   S1 | Support reports 32 bulk-editing tickets without removing repeated tickets from the same user.
   S2 | Product records 20 incomplete setups out of 50 new-use sessions; these are sessions, not people, and causes are unknown.
   S3 | One prospect asked about SSO. No contract commitment, value or delivery requirement is established.
   S4 | Each shipped feature must complete QA. Do not skip QA or substitute spare engineering/design capacity. Explain sequence, but treat calendar dates as assumptions pending scheduling checks.

   This is recorded response 1 from Claude Sonnet 5.5 on 28 October 2026. The Korean prompt requested both languages; this is the English portion of that same response, reproduced without editing. The surrounding explanation and checked deliverable are editorial writing.

   Example responseCopy

   A teaching example of a workflow in an external AI tool. Results vary with the request and context.

   AI Planning Review Sheet (practice, fictional data)

   1. Condition classification

   • Required: R1 include A (G1) / R2 per-role caps: dev 12, design 4, QA 2, no substitution across roles (G2) / R3 budget 3,600,000 KRW = 18 person-days x 200,000 (G3) / R4 every feature must complete QA; no skipping or substituting (S4) / R5 B starts only after A is done (F-B)
   • Optional requests: O1 B (multi-item edit), O2 C (first-use guide), O3 D (enterprise SSO)
   • Unverified evidence: U1 S1's 32 inquiries still include repeat inquiries from the same users, so the user count is unknown / U2 S2's 20 of 50 are sessions, not people, and the cause of drop-off is unknown / U3 S3 is one prospect asking about SSO; no contract, amount or deadline demand / U4 D's external vendor schedule is unknown / U5 C is a pre-validation estimate

   2. Calculation (person-days)

   Plan	Dev	Design	QA	Total	Cost (KRW)	Pass?
   A+B	9	2	2	13	2,600,000	Pass
   A+C	7	3	2	12	2,400,000	Pass
   A+B+C	12	4	3	19	3,800,000	Fail: QA over by 1; total over by 1 day and budget over by 200,000
   A+D	12	2	3	17	3,400,000	Fail: QA over by 1 (budget OK); vendor schedule unknown

   A+B and A+C use all 2 QA days, leaving no QA slack. A+B+C and A+D would only fit by cutting QA, which violates R4.

   3. Two feasible plans compared

   • A+B: leftover dev 3, design 2, budget 1,000,000. S1 is a demand signal tied to B, but because of U1 it is not converted into a reduction figure. B must wait for A, so the schedule is sequential and any A delay passes straight to B.
   • A+C: leftover dev 5, design 1, budget 1,200,000. C is independent of A and can run in parallel. But C is a U5 estimate, and due to U2 nothing can be said about improving setup completion.

   4. Recommended draft: A+B

   Finish A first, then do B. It keeps total and role caps, adds a feature with a clear dependency, and is backed by a real support-team signal. The 32 inquiries are a reference signal, not an effect figure, and the 20 of 50 incomplete setups are not used as evidence for C. Revisit C once its estimate is validated. Exclude D for now until S3 and the vendor schedule are clarified.

   5. Predecessors and successors (not fixed dates)

   A dev/design -> A QA -> (after A completes) B dev/design -> B QA -> release decision. C could run in parallel with A but is excluded from this recommendation. Any day-by-day plan is an assumption pending schedule confirmation; the two-week target is a requirement, not a commitment.

   6. Questions to confirm

   1. Converted to actual headcount, leave and calendar days, can the person-day caps be met in two weeks?
   2. Can the 2 QA days be available when A finishes and again when B finishes?
   3. After removing repeats, how many distinct users are behind the 32 inquiries?
   4. What causes the S2 drop-off, and what is the per-person figure?
   5. Can C's dev and design estimates be validated?
   6. Does the S3 prospect require a deadline or contract terms, and when will D's vendor schedule be known?

2. 4

   Use findings to change scope, not just the recommendation’s wording

   T1 reports that two of three fictional keyboard-only participants could not reach Save in the B prototype. This does not estimate a population failure rate. The decision-relevant facts are the observed blocked action and the rule that B cannot ship with that blocker. Supply both the scene and the release condition; a vague “usability concern” does not explain which work must be added.

   

   Repair M adds 2/1/1, making B+M equal 7/2/2. Including mandatory A gives 11/3/3, seventeen person-days and KRW 3.4m. Money remains, but QA capacity is exceeded. This is the critical calculation requested in the second turn. “Use the remaining budget” does not establish that an additional QA person-day is actually available or approved.

   T3 also narrows C after a prototype revealed that Next was mistaken for payment. Revised C2 requires 4/2/1. Claude changes the bundle from A+B to A+C2 and calculates 8/3/2, thirteen person-days and KRW 2.6m. The total equals the first recommendation, yet the actual features and role allocation differ. Asking for a before-and-after decision log makes that otherwise easy-to-miss change visible.

   The response briefly labels another comparison “A+B+C2” with four QA days. Under the new conditions B must include repair M, so the unambiguous label is A+B+M+C2. Without M, the old B estimate would produce three QA days. The editor’s checked version writes the repair explicitly. A condition the assistant implicitly remembers must also be visible to a teammate reading only the final table.

   Replan from the findings. Recalculate A+B+M and A+C2, rejecting a QA overrun even if money remains. Keep mandatory A. Produce revised scope, deferred work, role effort, cost, sequence, pre-release checks and a decision change log. Change the actual scope, not just the wording of the previous recommendation.
   
   T1 | In the fictional B prototype check, two of three keyboard-only participants could not reach Save. This tiny case does not estimate population prevalence. B cannot ship with the blocker.
   T2 | Repair M adds engineering 2, design 1 and QA 1 person-day to B's original estimate. Skipping repair or QA is prohibited.
   T3 | C's prototype check found Next was mistaken for a payment action. A narrower wording-and-sequence revision C2 requires engineering 4, design 2 and QA 1, replacing F-C.
   T4 | Mandatory A, capacity, budget and target date remain unchanged. No extra QA capacity is approved.

   This is recorded response 2 from Claude Sonnet 5.5 on 28 October 2026. The Korean prompt requested both languages; this is the English portion of that same response, reproduced without editing. The surrounding explanation and checked deliverable are editorial writing.

   Example responseCopy

   A teaching example of a workflow in an external AI tool. Results vary with the request and context.

   Revised Planning Review Sheet (practice, fictional data)

   1. Recalculation (person-days)

   Plan	Dev	Design	QA	Total	Cost (KRW)	Pass?
   A+B+M	4+7=11	1+2=3	1+2=3	17	3,400,000	Fail: QA 3 > 2 (money is left over, but the QA cap is exceeded)
   A+C2	4+4=8	1+2=3	1+1=2	13	2,600,000	Pass

   • B+M is dev 7, design 2, QA 2 (B's old 5/1/1 plus T2's 2/1/1). QA cannot be skipped and no unfixed release is allowed (T2), and no extra QA staff is approved (T4), so B does not fit this window.
   • A+B+C2 would need QA 4 and A+D QA 3, so both still fail.

   2. Revised plan: A + C2

   In scope

   • A: fast search (required, unchanged)
   • C2: the first-use guide narrowed to explanatory wording and step order. It uses T3's estimate, not the full C.

   On hold

   • B (+M): in T1, 2 of 3 keyboard-only participants could not reach the save button. B is not released with that defect, and fixing and re-verifying it needs extra QA, so it is out of this cap. Resume conditions: QA capacity secured and re-validation after the fix.
   • D (SSO): vendor schedule unknown and QA 3 exceeds the cap. Unchanged.
   • Any work in the original C beyond C2.

   3. Workload and cost by role

   	Dev	Design	QA	Total
   Used	8	3	2	13
   Cap	12	4	2	18
   Left	4	1	0	5

   Cost: 13 x 200,000 = 2,600,000 KRW, leaving 1,000,000 of budget. Leftover dev and design days are not used for B or any new scope, because nothing ships without QA and roles cannot substitute for each other.

   4. Work order (not fixed dates)

   1. A dev/design -> A QA (1 day)
   2. C2 dev/design -> C2 QA (1 day). C2 is independent of A and can run in parallel, but actual staffing is unconfirmed.
   3. Release decision after both QA passes. The target date is a requirement, not a commitment.

   5. Pre-release checks

   • QA complete for both A and C2 (no skipping or cross-role substitution)
   • Re-check with the revised mockup that the Next button is no longer mistaken for a payment button
   • Confirm B is off the release list until its defect is fixed
   • No effect figures: S1's 32 still include repeats; S2's 20 of 50 are sessions, not people, with the cause unknown. T1's 2 of 3 and T3's misreading are small fictional checks, not user-wide rates. Do not claim C2 reduces drop-off.

   6. Decision change table

   Item	Before	Now	Reason
   Recommendation	A+B	A+C2	T1/T2 push B over the QA cap
   B	Included	On hold	Keyboard defect; fix brings QA to 3
   C	Excluded	Included as C2	T3 validation, new 4/2/1 estimate
   Total / cost	13 / 2,600,000	13 / 2,600,000	Same numbers, different scope
   Leftover	Dev 3, design 2	Dev 4, design 1, QA 0	Scope swapped
   A, D, caps, budget		Unchanged	T4

   7. Questions to confirm

   1. Is there staffing to run A and C2 in parallel?
   2. Can the 2 QA days be used when A and C2 each finish?
   3. When will QA capacity for resuming B be available?

3. 5

   A usable plan preserves scope, sequence and the decision change

   The checked plan opens with A search plus the C2 wording-and-sequence revision, thirteen person-days. It then states engineering eight, design three, QA two and cost KRW 2.6m. Role totals stay visible because the QA limit changed the decision. The table and downloadable plan are editorially checked outputs, separate from the raw AI response, so the reader can identify where a person clarified its shorthand.

   

   Deferred work includes B+M and D with reconsideration conditions. B+M needs available QA capacity and a successful check after repairing the keyboard blocker. D needs supplier timing and better evidence of the prospect’s requirements. Deferred does not mean valueless forever; it means excluded under the current evidence and limits. Revise sweeping claims such as “unnecessary feature” into a scoped decision with a reason.

   The sequence places QA after preparation and development for each selected feature, then a release decision after both checks. Independence makes parallel work conceivable, not confirmed. Actual allocation of people is still unknown. Do not let AI fill a calendar with fabricated Monday/Tuesday commitments. Leave specific staffing questions so a scheduler can later convert the effort comparison into a real calendar.

   The change log connects old A+B to new A+C2 through T1’s blocked saving and T2’s extra QA. Add that equal costs hide changed scope, QA headroom is zero and the effect of C2 has not been established. Any claimed improvement in setup completion belongs among future verification questions. The deliverable is a reviewable execution plan with evidence, not a claim that features were shipped or outcomes improved.

   Revised plan after the AI exchange — editor-checked

   Item	Decision and basis
   Included	A + C2
   Role effort	Engineering 8; design 3; QA 2 person-days
   Budget	13×200,000 = KRW 2,600,000
   Deferred	B+M: QA limit; D: QA limit and supplier unknown
   Sequence	Each feature followed by QA, then release decision
   Future checks	Payment confusion for C2; keyboard saving after B repair

   Download the complete material

4. 6

   Recalculate when the staffing conditions change

   After checking the plan, introduce holdout H1: an absence lowers engineering capacity from twelve to seven person-days. Design four, QA two, the KRW 3.6m budget and mandatory A remain unchanged. Ask the assistant to apply that one change. A bounded change makes it possible to trace why the conclusion shifts instead of introducing several unexplained differences at once.

   A+C2 needs eight engineering days and now exceeds the limit by one. Its thirteen total days equal the new aggregate capacity of thirteen, but roles are not interchangeable. The recorded third reply rejects the bundle and proposes A alone: 4/1/1, six person-days and KRW 1.2m. Scope shrinks while preserving the mandatory feature.

   The remaining KRW 2.4m does not automatically create engineering availability. Additional people, authority to obtain them and time to mobilize them would need separate evidence. Nor can AI simply relabel C2 “small” and change four engineering days to three without a new estimate. Ask for the source of any revised number. Otherwise the plan appears feasible because its assumptions silently changed.

   The final change log should say C2 is deferred due to reduced capacity, not reduced value. The reply’s prose describes B’s engineering need broadly as “at least nine,” while the exact current A+B+M bundle is eleven engineering, three design and three QA days. Retain exact figures in the checked table. Re-adding the original estimates prevents a long conversation’s shorthand from replacing the underlying calculation.

   New staffing condition after the completed plan

   Item	Changed condition
   Engineering	12 → 7 person-days
   Unchanged	Design 4; QA 2; KRW 3.6m budget; mandatory A
   Retained constraints	B needs A and M; C uses the C2 estimate

   Download the complete material

   Apply only the holdout change and recheck A+C2. Calculate a feasible scope retaining mandatory A. Identify deferred work, the assumption that broke and questions for the scheduler. Remaining money cannot be interpreted as extra engineering capacity.
   
   H1 | Holdout: an absence lowers engineering capacity from 12 to 7 person-days. Design 4, QA 2, budget 3,600,000 and mandatory A are unchanged.
   H2 | B still requires A plus repair M. C still uses the C2 estimate. Shipping a known blocker or skipping QA remains prohibited.

   This is recorded response 3 from Claude Sonnet 5.5 on 28 October 2026. The Korean prompt requested both languages; this is the English portion of that same response, reproduced without editing. The surrounding explanation and checked deliverable are editorial writing.

   Example responseCopy

   A teaching example of a workflow in an external AI tool. Results vary with the request and context.

   Re-verification (practice, fictional data, applying H1)

   1. Recalculation (person-days)

   New caps: dev 7, design 4, QA 2 (13 total), budget 3,600,000 KRW.

   Plan	Dev	Design	QA	Total	Cost (KRW)	Pass?
   A+C2	8	3	2	13	2,600,000	Fail: dev 8 > 7 (over by 1)
   A+B+M	11	3	3	17	3,400,000	Fail: dev over by 4, QA over by 1
   A+D	12	2	3	17	3,400,000	Fail: dev over by 5, QA over by 1
   A alone	4	1	1	6	1,200,000	Pass

   A+C2 fits design, QA and budget, but is short 1 dev day. Leftover budget does not raise role caps and is not read as extra dev capacity, and roles cannot substitute for each other. The 13 total equals the overall cap, but the plan still fails on the dev role.

   2. Revised scope

   In: A (fast search) only, keeping the required condition. On hold

   • C2: needs 4 dev days, but only 3 remain after A. Shrinking it further needs a new estimate; it is not cut arbitrarily.
   • B (+M): requires A first and the M fix; dev 9 or more and QA 3, outside the caps.
   • D: dev 8, QA 2, plus an unknown vendor schedule.

   3. Workload and cost by role

   	Dev	Design	QA	Total
   Used	4	1	1	6
   Cap	7	4	2	13
   Left	3	3	1	7

   Cost: 6 x 200,000 = 1,200,000 KRW, leaving 2,400,000. Leftover days serve only as risk buffer, not as grounds to add scope. The spare QA day is not assigned until a target feature is decided.

   4. Work order (not fixed dates)

   A dev/design -> A QA -> release decision. C2 is a later candidate, reconsidered once the dev cap is confirmed. The target date is a requirement, not a commitment.

   5. Broken assumptions

   • That 12 dev days are available (now 7)
   • That 4 dev days remain after A+C2 (actually 1 short)
   • Parallel staffing that assumed nobody is absent
   • The expectation of shipping A and C2 together by the target date Still holding: design 4, QA 2, budget, A required, existing B and C2 estimates, no skipped QA or defective releases.

   6. Pre-release checks

   • A's QA completed (no skipping or substitution)
   • Held items (B, C2, D) are absent from the release list
   • No effect figures: S1's 32 still include repeats; S2's 20 of 50 are sessions, not people, with the cause unknown; T1's 2 of 3 and T3's misreading are small fictional checks.

   7. Decision change table

   Item	Before	Now	Reason
   Dev cap	12	7	H1
   Scope	A+C2	A alone	Dev 8 > 7
   C2	Included	On hold	1 dev day short
   B, D	On hold	On hold	Over caps (unchanged)
   Total / cost	13 / 2,600,000	6 / 1,200,000	Smaller scope

   8. Questions for the scheduling owner

   1. Is 7 dev days confirmed for the full two weeks, or does the absent person return on a known date?
   2. Was the absent person the owner of A? Can A's 4 days be placed first?
   3. If dev can rise by 1 day or more, when and who confirms it? (Not assumed until confirmed.)
   4. Are design 4 and QA 2 actually available when needed?
   5. Does releasing A alone satisfy the target-date requirement?

This is a learning check, not a test you must pass. Use the explanations to understand the ideas.

1. Q1AI passes A+D because its KRW 3.4m cost is within budget. Which column needs another check?

   Write your thoughts (optional)

   Write your thoughts (optional)

   Your writing is not sent anywhere. It disappears when you leave or reload this page, so copy anything you want to keep.

   Read the answer and explanation

   Recheck QA: A needs one day and D two, totaling three against two available. These are fictional practice values. Remaining money does not establish additional QA capacity.

   I read and understood the explanation

   This is your own review, not an automatic score.

2. Q2After T1/T2, AI recommends A+B+M but reduces QA to two days. Is that supported?

   Write your thoughts (optional)

   Write your thoughts (optional)

   Your writing is not sent anywhere. It disappears when you leave or reload this page, so copy anything you want to keep.

   Read the answer and explanation

   No. A, B and M each require one QA day, and T2 prohibits skipping verification. The invented budget permits the cost, but the current capacity does not. Compare another feasible option such as A+C2.

   I read and understood the explanation

   This is your own review, not an automatic score.

3. Q3A+B and A+C2 both cost KRW 2.6m. Can the change log say nothing changed?

   Write your thoughts (optional)

   Write your thoughts (optional)

   Your writing is not sent anywhere. It disappears when you leave or reload this page, so copy anything you want to keep.

   Read the answer and explanation

   No. Scope and role allocation changed despite the same fictional total. Engineering changes from nine to eight, design from two to three, and C2 replaces B. Record T1/T2 as the reason for changing scope.

   I read and understood the explanation

   This is your own review, not an automatic score.

4. Q4After H1, AI says the KRW 2.4m remaining after A can fund C2 too. Which condition defeats that claim?

   Write your thoughts (optional)

   Write your thoughts (optional)

   Your writing is not sent anywhere. It disappears when you leave or reload this page, so copy anything you want to keep.

   Read the answer and explanation

   Compare seven available engineering days with the eight required by A+C2. The fictional case lacks one day, and no source permits replacing it with money or another role. Retain A or obtain a confirmed resource change or new estimate before reconsidering.

   I read and understood the explanation

   This is your own review, not an automatic score.

1. 7

   Try it: explain an AI revision with its deciding constraint

   Without a tool, explain why A+D is rejected in one sentence: its KRW 3.4m cost fits, but three QA days exceed the available two. Then connect the switch from A+B to A+C2 to T1 and T2. Combining the conclusion, deciding constraint and source ID makes an AI-generated plan easier to explain to another person.

   For optional practice, provide only the initial source pack and save the reply. Add T1–T4 and request a change log, then introduce H1/H2. Compare included features and role totals, not just cost. The first two recommendations in this run both cost KRW 2.6m, so a budget-only comparison would miss the scope change. Retaining the conversation makes that difference inspectable.

   Begin with three effort columns instead of a large calendar. Add engineering, design and QA for one bundle, compare against capacity and independently re-add a row of the assistant’s result. An alternative recommendation may be reasonable if it preserves mandatory A, dependencies, role limits and verification conditions. Matching the model’s exact prose is not the learning objective.

   Finish with included work, deferred work, the reason for the change and the next questions. Under H1, include A and defer C2 for lack of one engineering day, then check actual allocation and QA timing. In real work, replace every invented estimate with the team’s confirmed values. AI has helped construct a reviewable decision, not proved a delivery date or a customer outcome.