11 ਦਸੰ 2025·8 ਮਿੰਟ
ਸੁਰੱਖਿਅਤ, ਛੋਟੇ iterations ਲਈ “ਬਦਲ ਨਾ ਕਰੋ” ਪ੍ਰੌਂਪਟ ਪੈਟਰਨ
ਇਕੱਲੇ ਇਕ ਛੋਟੀ ਅਪਡੇਟ ਲਈ “ਬਦਲ ਨਾ ਕਰੋ” ਪ੍ਰੌਂਪਟ ਪੈਟਰਨ ਸਿੱਖੋ, ਜੋ ਮੁੱਖ UI ਫਲੋ, ਬਿਜ਼ਨਸ ਨਿਯਮ ਅਤੇ ਆਵਸ਼ਪਦਤ ਵਿਹਾਰ ਨੂੰ ਫ੍ਰੀਜ਼ ਕਰਕੇ ਹੋਰ ਡ੍ਰਿਫਟ ਰੋਕਦਾ ਹੈ।
ਇਕੱਲੇ ਇਕ ਛੋਟੀ ਅਪਡੇਟ ਲਈ “ਬਦਲ ਨਾ ਕਰੋ” ਪ੍ਰੌਂਪਟ ਪੈਟਰਨ ਸਿੱਖੋ, ਜੋ ਮੁੱਖ UI ਫਲੋ, ਬਿਜ਼ਨਸ ਨਿਯਮ ਅਤੇ ਆਵਸ਼ਪਦਤ ਵਿਹਾਰ ਨੂੰ ਫ੍ਰੀਜ਼ ਕਰਕੇ ਹੋਰ ਡ੍ਰਿਫਟ ਰੋਕਦਾ ਹੈ।
ਇੱਕ “ਛੋਟਾ” ਬਦਲ ਅਕਸਰ ਛੋਟਾ ਹੀ ਰਹਿੰਦਾ ਨਹੀਂ। ਤੁਸੀਂ ਇੱਕ ਬਟਨ ਦਾ ਲੇਬਲ ਥੋੜ੍ਹਾ ਬਦਲਣ ਲਈ ਕਹਿੰਦੇ ਹੋ, ਅਤੇ ਇਕੱਦਮ ਪੇਜ਼ ਲੇਆਉਟ ਸੁੱਟ ਜਾਂਦਾ ਹੈ, ਫਾਰਮ ਵੈਧਤਾ ਰੁਕ ਜਾਂਦੀ ਹੈ, ਜਾਂ ਚੈਕਆਉਟ ਕਦਮ ਵੱਖਰਾ ਵਰਤਾਅ ਕਰਨ ਲੱਗਦਾ ਹੈ। ਐਪ ਇਕ-ਦੂਜੇ ਨਾਲ ਜੁੜੇ ਹੋਏ ਸਿਸਟਮ ਹੁੰਦੇ ਹਨ। UI, ਲੌਜਿਕ, ਡੇਟਾ, ਅਤੇ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਸਭ ਇਕ-ਦੂਜੇ 'ਤੇ ਨਿਰਭਰ ਹੁੰਦੇ ਹਨ.
ਆਮ ਕਾਰਨ ਅਸਪੱਸ਼ਟ ਸੀਮਾਵਾਂ ਹੁੰਦੀਆਂ ਹਨ। ਜੇ ਕੋਈ ਬੇਨਤੀ ਕਹੇ “ਸਾਈਨਅਪ ਸਧਾਰਨ ਕਰੋ,” ਤਾਂ ਬਣਾਉਣ ਵਾਲਾ (ਇਨਸਾਨ ਜਾਂ AI) ਨੂੰ ਇਹ ਅਨੁਮਾਨ ਲਗਾਉਣਾ ਪੈਂਦਾ ਹੈ ਕਿ “ਸਧਾਰਨ” ਦਾ ਕੀ ਮਤਲਬ ਹੈ। ਅਨੁਮਾਨ ਹੋਰ ਸੋਧਾਂ ਵੱਲ ਲੈ ਜਾਂਦਾ ਹੈ: ਫੀਲਡ ਹਟਾਉਣ, ਕਦਮ ਬਦਲਣ, ਕਾਪੀ ਐਡਜਸਟ ਕਰਨ, ਜਾਂ ਵੈਧਤਾ ਦੁਬਾਰਾ ਲਿਖਣ। ਇਕ ਹੋਰ ਕਾਰਨ ਲੁਕਵੇਂ ਨਿਰਭਰਤਾਵਾਂ ਹਨ। ਇੱਕ ਨਿੱਜੀ UI ਬਦਲ ਇਕ ਐਸਾ ਕੰਪੋਨੈਂਟ ਵਰਤ ਸਕਦਾ ਹੈ ਜੋ ਪੰਜ ਹੋਰ ਸਕ੍ਰੀਨਾਂ 'ਤੇ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ।
ਇੱਕ ਸੁਰੱਖਿਅਤ iteration ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਸੀਂ ਪਰਤਿਆਸ਼ਿਤ ਸੁਧਾਰ ਮਿਲੇ ਅਤੇ ਬਾਕੀ ਸਭ ਕੁਝ ਪ੍ਰਭਾਵੀ ਤੌਰ 'ਤੇ ਇਕੋ ਜਿਹਾ ਹੀ ਰਹੇ। ਗੈਰ-ਟੈਕਨੀਕਲ ਟੀਮ ਲਈ ਇਹ ਮਤਲਬ ਹੈ ਕਿ ਵਰਤੋਂਕਾਰਾਂ ਲਈ ਵਰਕਫਲੋ ਉਹੀ ਮਹਿਸੂਸ ਹੋਵੇ, ਸਪੋਰਟ ਸਕ੍ਰਿਪਟ ਉਤਨੇ ਹੀ ਸਹੀ ਰਹਿਣ, ਅਤੇ ਰਿਪੋਰਟਿੰਗ ਦਾ ਮਤਲਬ ਉਤਨਾ ਹੀ ਬਣਿਆ ਰਹੇ। ਟੈਕਨੀਕਲ ਟੀਮ ਲਈ ਇਹ ਮਤਲਬ ਹੈ ਕਿ ਰੂਟਸ, ਡੇਟਾ ਆਕਾਰ, API ਠੇਕੇ, ਜਾਂ edge-case ਵਿਹਾਰ ਵਿੱਚ ਅਚਾਨਕ ਬਦਲਾਅ ਨਾ ਹੋਵੇ।
ਇਹ ਸੰਭਵ ਬਣਾਉਣ ਲਈ, ਤੁਹਾਨੂੰ ਉਹ ਚੀਜ਼ਾਂ ਫ੍ਰੀਜ਼ ਕਰਨੀ ਪੈਣਗੀਆਂ ਜੋ ਹਿਲਣ ਨਹੀਂ ਚਾਹੀਦੀਆਂ। ਅਮਲ ਵਿੱਚ, ਇਸ ਵਿੱਚ ਆਮ ਤੌਰ 'ਤੇ ਨਿਰਣਾਇਕ ਫਲੋ (ਉਹ ਇਕੱਠੇ ਕਦਮ ਜੋ ਯੂਜ਼ਰ ਲੈਂਦੇ ਹਨ), UI ਅਤੇ UX ਵੇਰਵੇ (ਲੇਆਉਟ, ਸਪੇਸਿੰਗ, ਇੰਟਰੈਕਸ਼ਨ ਵਿਹਾਰ), ਬਿਜ਼ਨਸ ਨਿਯਮ (ਕੀਮਤ, ਅਨੁਮਤੀਆਂ, ਵੈਧਤਾ), ਡੇਟਾ ਵਿਹਾਰ (ਕੀ ਸਟੋਰ ਹੁੰਦਾ ਹੈ ਅਤੇ ਕਦੋਂ), ਅਤੇ ਇੰਟੀਗ੍ਰੇਸ਼ਨ (ਅਨਾਲਿਟਿਕਸ ਇਵੈਂਟ, ਈਮੇਲ, ਭੁਗਤਾਨ, ਬਾਹਰੀ APIs) ਸ਼ਾਮਿਲ ਹੁੰਦੇ ਹਨ।
ਇਹ “ਬਦਲਣਾ ਨਹੀਂ” ਪ੍ਰੌਂਪਟ ਪੈਟਰਨ ਜੋਖਮ ਘਟਾਉਂਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਅਨੁਮਾਨਬਾਜ਼ੀ ਨੂੰ ਹਟਾ ਦਿੰਦਾ ਅਤੇ ਬਦਲ ਨੂੰ ਸੀਮਿਤ ਰੱਖਦਾ ਹੈ। ਇਹ ਗਾਰੰਟੀ ਨਹੀਂ ਹੈ। ਜੇ ਮੂਲ ਵਿਹਾਰ ਚੰਗੀ ਤਰ੍ਹਾਂ ਪਰਿਭਾਸ਼ਿਤ ਨਹੀਂ, ਜੇ ਬਦਲ ਸਾਂਝੇ ਕੰਪੋਨੈਂਟਾਂ ਨੂੰ ਛੂਹਦਾ ਹੈ, ਜਾਂ ਜੇ ਤੁਸੀਂ ਨਤੀਜੇ ਦੀ ਜਾਂਚ ਨਹੀਂ ਕਰਦੇ ਤਾਂ ਡ੍ਰਿਫਟ ਹੋ ਸਕਦੀ ਹੈ। ਲਕੜੀ ਦਾ ਮਕਸਦ ਘੱਟ ਹੈਰਾਨੀਆਂ ਅਤੇ ਤੇਜ਼ ਮਨਜ਼ੂਰੀਆਂ ਹਨ।
ਬਦਲ ਨਾ ਕਰੋ ਪ੍ਰੌਂਪਟ ਪੈਟਰਨ ਇਕ ਸਧਾਰਣ ਤਰੀਕਾ ਹੈ ਇੱਕ ਖਾਸ ਅਪਡੇਟ ਮੰਗਣ ਦਾ ਜਦੋਂ ਤੁਸੀਂ ਸਾਰੀ ਹੋਰ ਚੀਜ਼ਾਂ ਨੂੰ ਲਾਕ ਕਰ ਦੇਣਾ ਚਾਹੁੰਦੇ ਹੋ। ਤੁਹਾਨੂੰ ਉਸ ਇਕ ਬਦਲ ਨੂੰ ਨਾਮਿਤ ਕਰਨਾ ਹੈ ਜੋ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ, ਫਿਰ ਉਹਨਾਂ ਚੀਜ਼ਾਂ ਦੀ ਛੋਟੀ ਫ੍ਰੀਜ਼ ਲਿਸਟ ਲਿਖੋ ਜੋ ਅਪਡੇਟ ਬਾਅਦ ਇਕੋ ਜਿਹੀਆਂ ਰਹਿਣੀ ਚਾਹੀਦੀਆਂ ਹਨ।
ਇਹ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਮਾਡਲ ਅਕਸਰ ਲੋੜ ਤੋਂ ਵੱਧ ਮਦਦਗਾਰ ਹੋਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ — ਫਾਇਲਾਂ ਨੂੰ ਰੀਫੈਕਟਰ ਕਰਨਾ, ਨਾਮ ਬਦਲਣਾ, ਫਾਇਲਾਂ ਨੂੰ ਮੁੜ ਸੰਗਠਿਤ ਕਰਨਾ, ਜਾਂ ਲੌਜਿਕ “ਸਾਫ” ਕਰਨਾ। ਭਾਵੇਂ ਨਤੀਜਾ ਕੰਮ ਕਰਦਾ ਹੋਵੇ, ਇਹ ਵਾਧੂ ਬਦਲਾਅ ਬੱਗ ਪੈਦਾ ਕਰ ਸਕਦੇ ਹਨ, ਵਿਹਾਰ ਬਦਲ ਸਕਦੇ ਹਨ, ਜਾਂ ਰਿਵਿਊਅਾਂ ਨੂੰ ਮੁਸ਼ਕਲ ਕਰ ਸਕਦੇ ਹਨ।
ਇਹ ਦੋ ਬੇਨਤੀਆਂ ਦੀ ਤੁਲਨਾ ਕਰੋ:
“Make the settings page better.” ਇਹ ਡਿਜ਼ਾਈਨ ਬਦਲ, ਨਵਾਂ ਕਾਪੀ, ਲੇਆਉਟ ਬਦਲਣ ਅਤੇ ਲੌਜਿਕ ਸੋਧਣ ਨੂੰ ਬੁਲਾਂਦਾ ਹੈ।
“Change only the label text from ‘Phone’ to ‘Mobile phone’. Do not change layout, validation, or the save behavior.” ਇਹ ਸੰਗੀਨ, ਟੈਸਟ ਕਰਨ ਯੋਗ, ਅਤੇ ਸੁਰੱਖਿਅਤ ਹੈ।
ਇੱਕ ਮਜ਼ਬੂਤ ਫ੍ਰੀਜ਼ ਲਿਸਟ ਆਮ ਤੌਰ 'ਤੇ ਤਿੰਨ ਖੇਤਰ ਕਵਰ ਕਰਦੀ ਹੈ:
ਜਦੋਂ ਤੁਸੀਂ ਇਹ ਪੈਟਰਨ ਚੈਟ-ਆਧਾਰਿਤ ਬਣਾਉਣ ਦੇ ਸੰਦ (ਉਦਾਹਰਨ ਵਜੋਂ Koder.ai) ਵਿੱਚ ਵਰਤਦੇ ਹੋ, iteration ਤੇਜ਼ ਹੁੰਦੀ ਹੈ ਕਿਉਂਕਿ ਮਾਡਲ ਇਕ-ਲਾਈਨ ਸੋਧ 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਿਤ ਕਰਦਾ ਹੈ ਬਜਾਏ ਅਣਚਾਹੀਆਂ ਸੁਧਾਰਾਂ ਦੇ।
ਇਹ ਪੈਟਰਨ ਸਭ ਤੋਂ ਵਧੀਆ ਤਬ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦੋਂ ਤੁਹਾਡੀ ਬੇਨਤੀ ਇੱਕ ਛੋਟੇ ਠੇਕੇ ਵਰਗੀ ਲੱਗੇ: ਇੱਕ ਸਪਸ਼ਟ ਮਕਸਦ, ਇੱਕ ਫ੍ਰੀਜ਼ ਲਿਸਟ ਜੋ ਦੱਸਦੀ ਹੈ ਕੀ ਇਕੋ ਜਿਹਾ ਰਹੇਗਾ, ਅਤੇ ਕੁਝ ਚੈੱਕਜ਼ ਨਤੀਜੇ ਦੀ ਪੁਸ਼ਟੀ ਲਈ।
ਇਸ ਟੈਮਪਲੇਟ ਨੂੰ ਕਾਪੀ ਕਰੋ ਅਤੇ ਕੋਠੜੀਆਂ ਭਰੋ। ਛੋਟਾ ਰਹੋ ਪਰ ਵਿਸ਼ੇਸ਼।
Goal (one sentence):
- Change: [describe the one small change you want]
Context (1-3 sentences):
- Current behavior: [what happens today]
- Desired behavior: [what should happen after]
DO NOT CHANGE (must remain identical):
- Critical flows: [e.g., sign up -> checkout -> receipt stays the same]
- UI/UX that must not move: [e.g., button location, labels, navigation order]
- Business rules: [e.g., pricing, permissions, validation rules]
- Data behavior: [e.g., database schema, stored fields, migration rules]
Constraints (limit drift):
- Scope: [only this screen / only this endpoint / only this component]
- Files/modules (if known): [list a couple, or say “only touch what’s necessary”]
- No refactors: do not rename, reorganize folders, or change formatting beyond the touched lines
Acceptance checks (how I will verify):
1) [a simple before/after check]
2) [a user path that must still work]
3) [a rule that must still hold]
Output requested:
- Provide a brief diff-style summary: what changed, where, and why
- Call out any risk or unclear requirement before implementing
ਇਕ ਮਿਸਾਲ: ਜੇ ਤੁਸੀਂ ਚੈਕਆਉਟ ਬਟਨ ਦਾ ਰੰਗ ਬਦਲਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਡਾ ਗੋਲ ਹੋਵੇਗਾ “Update the primary checkout button color to #1A73E8.” ਤੁਹਾਡੇ DO NOT CHANGE ਆਈਟਮਾਂ ਨੂੰ ਪੂਰੇ ਚੈਕਆਉਟ ਫਲੋ, ਬਟਨ ਟੈਕਸਟ, ਅਤੇ ਕੀਮਤ ਦੀ ਗਣਨਾ ਫ੍ਰੀਜ਼ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ।
ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਤ ਰਹੇ ਹੋ, ਇਹ ਫਾਰਮੈਟ ਰਿਵਿਊਜ਼ ਨੂੰ ਤੇਜ਼ ਕਰਦਾ ਹੈ ਕਿਉਂਕਿ ਤੁਸੀਂ acceptance checks ਨੂੰ preview ਅਤੇ change summary ਨਾਲ ਮਿਲਾ ਕੇ ਮਨਜ਼ੂਰੀ ਦੇ ਸਕਦੇ ਹੋ।
ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ ਛੋਟੀ ਬਦਲ ਦੀ ਮੰਗ ਕਰਦੇ ਹੋ, ਤਾਂ “ਕੁਝ ਵੀ ਨਹੀਂ ਟੋੜੋ” ਕਹਿਣ ਦੀ ਥਾਂ, ਉਸੇ ਯੂਜ਼ਰ ਜਰਨੀਆਂ ਨੂੰ ਨਾਮ ਦਿਓ ਜਿਨ੍ਹਾਂ ਨੂੰ ਤੁਹਾਨੂੰ ਇਕੋ ਜਿਹੀਆਂ ਰੱਖਣਾ ਹੈ, ਪਹਿਲੇ ਕਲਿੱਕ ਤੋਂ ਅੰਤਲੇ ਨਤੀਜੇ ਤੱਕ। ਤੁਸੀਂ ਪੂਰੇ ਐਪ ਨੂੰ ਫ੍ਰੀਜ਼ ਨਹੀਂ ਕਰ ਰਹੇ, ਤੁਸੀਂ ਉਹ ਹਿੱਸੇ ਜਿੰਨ੍ਹਾਂ ਵਿੱਚ ਰਿਗਰੈਸ਼ਨ ਨੁਕਸਾਨ ਪਹੁੰਚਾਉਂਦੇ ਹਨ, ਉਨ੍ਹਾਂ ਨੂੰ ਫ੍ਰੀਜ਼ ਕਰ ਰਹੇ ਹੋ।
ਸ਼ੁਰੂਆਤ ਕਰੋ ਠੀਕ ਭਾਸ਼ਾ 'ਚ ਮਹੱਤਵਪੂਰਨ ਫਲੋ ਲਿਖ ਕੇ: login (password reset ਸਮੇਤ), onboarding, checkout, settings. ਹਰ ਫਲੋ ਲਈ ਦੱਸੋ ਕਿ "ਮੁੱਕ ਗਿਆ" ਕੀ ਦਿਖਦਾ ਹੈ। ਉਦਾਹਰਨ: “User can log in with email + password, lands on Dashboard, and stays signed in after refresh.”
ਫਿਰ ਉਹ ਐਡਜ ਕੇਸ ਲਾਕ ਕਰੋ ਜੋ ਲੋਕ ਭੁੱਲ ਜਾਂਦੇ ਹਨ। ਬੈਕ ਬਟਨ ਦਾ ਵਿਹਾਰ ਇੱਕ ਆਮ ਸਰੋਤ ਹੈ: “Back from Checkout returns to Cart (not Home), and cart items remain.” ਐਰਰ ਸਟੇਟਸ, ਫੁੱਲ ਹੋਏ ਹਾਲਾਤ, ਅਤੇ ਲੋਡਿੰਗ ਸਟੇਟਸ ਨੂੰ ਵੀ ਕਾਲ ਆਉਟ ਕਰੋ।
ਜੇ ਪੇਰਫਾਰਮੈਂਸ ਅਤੇ ਸੁਰੱਖਿਆ ਮਹੱਤਵਪੂਰਨ ਹਨ, ਉਹਨਾਂ ਨੂੰ ਵੀ ਫ੍ਰੀਜ਼ ਕਰੋ। ਜੇ ਤੁਸੀਂ ਇਨ੍ਹਾਂ ਨੂੰ ਨਹੀਂ ਦੱਸੋਗੇ, ਮਾਡਲ ਹੋਰ ਖੇਡਾਂ ਸ਼ਾਮਿਲ ਕਰ ਸਕਦਾ ਹੈ।
ਇਕ ਟਾਈਟ ਤਰੀਕਾ:
ਇੱਕ ਵਾਕ ਵਿੱਚ ਡੇਟਾ ਫਲੋ ਬਾਰੇ ਵਿਸ਼ੇਸ਼ ਹੋਵੋ। ਉਦਾਹਰਨ: “Address is saved only after pressing Save, stored in the user profile record, and must persist after logout/login.” ਇਹ ਪੱਧਰ ਅਤੇ ਵਾਰ-ਵਰ ਹੋਣ ਵਾਲੀਆਂ ਗਲਤੀਆਂ ਨੂੰ ਰੋਕਦਾ ਹੈ।
UI ਡ੍ਰਿਫਟ ਆਮਤੌਰ 'ਤੇ ਇਸ ਲਈ ਹੁੰਦੀ ਹੈ ਕਿਉਂਕਿ ਮਾਡਲ “ਮਦਦਗਾਰ” ਹੋ ਕੇ ਸਟਾਈਲ, ਸਪੇਸਿੰਗ, ਜਾਂ ਕੰਪੋਨੈਂਟ ਸਟ੍ਰਕਚਰ ਸਾਫ਼ ਕਰ ਦਿੰਦਾ ਹੈ। ਠੀਕ ਕਰਨ ਦਾ ਤਰੀਕਾ ਉਹੀ ਹੈ ਜੋ ਬਿਜ਼ਨਸ ਲੌਜਿਕ ਲਈ ਵਰਤਿਆ ਗਿਆ ਸੀ: ਜੋ ਇਕੋ ਜਿਹਾ ਰਹਿਣਾ ਹੈ ਉਸ ਨੂੰ ਨਾਮ ਦਿੱਤਾ ਜਾਵੇ, ਅਤੇ ਇੱਕੋ ਇੱਕ ਚੀਜ਼ ਜੋ ਬਦਲਣ ਦੀ ਇਜਾਜ਼ਤ ਹੈ, ਉਹ ਨਾਮਿਤ ਕਰੋ।
ਦਿੱਖ-ਵਿਅਕਤੀ ਨੂੰ ਪੱਕਾ ਕਰੋ। ਲੇਆਉਟ (ਕੋਲਮ/ਰੋਜ਼, ਹੈਡਰ ਅਤੇ ਫੁੱਟਰ ਪਲੇਸਮੈਂਟ), ਸਪੇਸਿੰਗ ਨਿਯਮ (padding, gaps, alignment), ਅਤੇ ਕੰਪੋਨੈਂਟ ਵਿਵਹਾਰ (hover, disabled state, loading spinners, error messages) ਨੂੰ ਕਾਲ ਆਉਟ ਕਰੋ। ਜੇ ਕਿਸੇ ਕੰਪੋਨੈਂਟ ਦਾ ਇੱਕ ਨਿਰਧਾਰਤ ਫੀਲ ਹੈ, ਸਿੱਧਾ ਲਿਖੋ: “Button size, radius, and color must stay exactly the same.”
ਰਿਸਪਾਂਸਿਵ ਵਿਹਾਰ ਲਈ ਖਾਸ ਨਿਯਮ ਦਿਓ। ਜੇ ਤੁਸੀਂ ਮੋਬਾਈਲ ਦਾ ਜ਼ਿਕਰ ਨਹੀਂ ਕਰਦੇ, ਟੂਲ ਇਸਨੂੰ “ਸੁਧਾਰ” ਕਰਨਗੇ। ਬਰੇਕਪੌਇੰਟ ਅਤੇ ਉਨ੍ਹਾਂ 'ਤੇ ਹੋਣ ਵਾਲੀ ਵਿਹਾਰ ਦੀ ਗੱਲ ਕਰੋ।
ਸ਼ਬਦਾਂ ਨੂੰ ਵੀ ਫ੍ਰੀਜ਼ ਕਰੋ। ਮਾਡਲ ਨੂੰ ਦੱਸੋ ਕਿ ਸਾਰਾ ਕਾਪੀ, ਲੇਬਲ, ਪਲੇਸਹੋਲਡਰ, ਅਤੇ ਹੈਲਪਰ ਟੈਕਸਟ ਬਦਲਨਾ ਮਨਾਹੀ ਹੈ, ਸਿਵਾਏ ਉਸ ਇਕ ਲੇਬਲ ਦੇ ਜੋ ਤੁਸੀਂ ਸੋਧ ਰਹੇ ਹੋ। ਇਹ ਗੁਪਤ ਰੀਰਾਈਟਾਂ ਨੂੰ ਰੋਕਦਾ ਹੈ।
ਸੰਖੇਪ ਪ੍ਰੌਂਪਟ:
ਜੇ ਸਕੇ, ਬੀਫੋਰ/ਆਫਟਰ ਸਕ੍ਰੀਨਸ਼ਾਟ ਮੰਗੋ। ਜੇ ਸਕ੍ਰੀਨਸ਼ਾਟ ਨਹੀਂ ਹਨ, ਇਕ ਛੋਟੀ “UI diff” ਵਰਣਨਾ ਮੰਗੋ (ਕੀ ਹਿਲਿਆ, ਕੀ ਰੀਸਾਈਜ਼ ਹੋਇਆ, ਕੀ ਰੰਗ ਬਦਲਿਆ) ਤਾਂ ਕਿ ਤੁਸੀਂ ਆਸਾਨੀ ਨਾਲ ਮਨਜ਼ੂਰੀ ਦੇ ਸਕੋ।
ਬਿਜ਼ਨਸ ਨਿਯਮ ਉਹਨਾਂ ਸਥਾਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹਨ ਜਿੱਥੇ ਇੱਕ ਛੋਟੀ UI ਬਦਲ ਇੱਕ ਖਾਮੋਸ਼ ਰਿਗਰੈਸ਼ਨ ਪੈਦਾ ਕਰ ਸਕਦੀ ਹੈ। ਇੱਕ ਲੇਬਲ ਅਪਡੇਟ ਗਣਨਾ, ਸਥਿਤੀ ਟ੍ਰਾਂਜ਼ੀਸ਼ਨ, ਜਾਂ ਕਿਸ ਨੂੰ ਰਿਕਾਰਡ ਵੇਖਣ ਦੀ ਆਗਿਆ ਹੈ, ਉਹ ਬਦਲ ਸਕਦਾ ਹੈ। ਨਿਯਮਾਂ ਅਤੇ ਡੇਟਾ ਵਿਹਾਰ ਨੂੰ ਇਕ ਠੇਕਾ ਵਾਂਗ ਫ੍ਰੀਜ਼ ਮੰਨੋ।
ਸਭ ਤੋਂ ਜ਼ਰੂਰੀ ਨਿਯਮਾਂ ਨੂੰ ਪਹਿਚਾਨੋ ਜੋ ਡ੍ਰਿਫਟ ਹੋਣ 'ਤੇ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਨੁਕਸਾਨ ਕਰਦੇ ਹਨ। ਉਨ੍ਹਾਂ ਨੂੰ ਟੈਸਟਾਂ ਵਾਂਗ ਲਿਖੋ: ਇੰਪੁੱਟ, ਆਊਟਪੁੱਟ, ਅਤੇ ਕੌਣ ਕੀ ਕਰ ਸਕਦਾ ਹੈ।
“ਕੀਮਤ ਨੂੰ ਉਹੀ ਰੱਖੋ” ਕਹਿਣ ਦੀ ਥਾਂ, ਇਹ ਨਿਰਧਾਰਤ ਕਰੋ:
ਇੱਕ ਨੰਬਰ ਉਦੇਹਰਨ ਦੇ ਨਾਲ ਵਿਵਰਣ ਦਿਓ ਤਾਂ ਕਿ ਕੋਈ ਵਿਆਖਿਆ ਨਾ ਰਹਿ ਜਾਵੇ। ਉਦਾਹਰਨ: “Order subtotal $120, discount 10% (applies before tax), tax 8.25% on discounted amount. Expected total = (120 - 12) * 1.0825 = $116.91. Rounding to 2 decimals only at the final total.”
ਰੋਲ-ਆਧਾਰਿਤ ਦਿਖਾਈ ਦੀ ਵੀ ਗੱਲ ਕਰੋ: “Support agents can view order status and customer email, but must not see full card details. Only admins can issue refunds.”
ਜੇ validation ಮುಖ್ಯ ਹੈ, ਉਹਨਾਂ ਨੂੰ ਖਾਸ ਤੌਰ 'ਤੇ ਫ੍ਰੀਜ਼ ਕਰੋ ਅਤੇ ਯੂਜ਼ਰ-ਦੇਖਣ ਵਾਲਾ ਸੁਨੇਹਾ ਵੀ ਦੱਸੋ। ਉਦਾਹਰਨ: “If start date is after end date, block save and show: ‘End date must be after start date.’ Do not change this wording.”
ਐਪ ਬਾਹਰ ਦੇ ਸਾਈਡ-ਏਫੈਕਟਸ ਨੂੰ ਨਾ ਭੁੱਲੋ। ਜੇ ਤੁਸੀਂ ਈਮੇਲ, webhook, ਜਾਂ ਤੀਜੀ-ਪੱਖੀ APIs ਨੂੰ ਕਾਲ ਕਰਦੇ ਹੋ, ਉਨ੍ਹਾਂ ਦੀਆਂ ਘਟਨਾਵਾਂ, ਪੇਲੋਡ ਫੀਲਡ, ਸਮਾਂ (ਤੁਰੰਤ ਜਾਂ ਦੇਰ), ਅਤੇ idempotency ਵਿਹਾਰ ਨੂੰ ਫ੍ਰੀਜ਼ ਕਰੋ।
ਇੱਕ ਛੋਟੀ ਅਪਡੇਟ ਨੂੰ ਇਕ ਨੈਨੇ ਠੇਕੇ ਵਾਂਗ ਇਲਾਜ ਕਰੋ। ਇਹ ਪੈਟਰਨ ਸਭ ਤੋਂ ਵਧੀਆ ਤਬ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦੋਂ ਬਦਲ ਸੀਮਿਤ ਹੋਵੇ ਅਤੇ ਬਾਕੀ ਸਾਰਾ ਕੁਝ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਲਾਕ ਕੀਤਾ ਹੋਵੇ।
ਬਦਲ ਨੂੰ ਇੱਕ ਟੈਸਟ ਕਰਨ ਯੋਗ ਵਾਕ ਵਿੱਚ ਲਿਖੋ। “On the settings page, add a toggle to enable dark mode” ਟੈਸਟ ਕਰਨ ਯੋਗ ਹੈ। “Improve the settings UI” ਨਹੀਂ। ਜੇ ਤੁਸੀਂ 30 ਸਕਿੰਟ ਵਿੱਚ ਟੈਸਟ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਤਾਂ ਇਹ ਹੁਣੇ ਵੀ ਬਹੁਤ ਵਿਸਤਾਰ ਹੈ।
ਉਹ ਹਿੱਸੇ ਲਿਖੋ ਜੋ ਡ੍ਰਿਫਟ ਹੋਣ 'ਤੇ ਨੁਕਸਾਨ ਪਹੁੰਚਦੇ ਹਨ: ਯੂਜ਼ਰ ਫਲੋ, ਮੂੰਹ-ਮੁੱਖ UI ਤੱਤ, ਬਿਜ਼ਨਸ ਨਿਯਮ, ਡੇਟਾ ਵਿਹਾਰ, ਅਤੇ ਕੋਈ APIs ਜਾਂ ਡੇਟਾਬੇਸ ਟੇਬਲ ਜੋ ਇਕੋ ਜਿਹੀ ਰਹਿਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ।
acceptance checks ਅਤੇ ਇੱਕ ਛੋਟਾ ਟੈਸਟ ਪਲਾਨ ਸ਼ਾਮਿਲ ਕਰੋ। ਇਹ ਥਾਂ ਹੈ ਜੋ ਤੁਸੀਂ “ਇਹ ਮੇਰੇ ਪਾਸ ਕੰਮ ਕਰਦਾ ਹੈ” ਦੇ ਹੈਰਾਨੀ ਨੂੰ ਰੋਕਦੇ ਹੋ। ਚੇਕਲਿਸਟ ਸ਼ਾਮਿਲ ਕਰੋ: ਨਵੀਂ toggle ਦਿੱਸਦੀ ਹੈ, ਮੌਜੂਦਾ ਸੈਟਿੰਗਜ਼ ਸੇਵ ਹੁੰਦੀਆਂ ਰਹਿੰਦੀਆਂ ਹਨ, ਅਤੇ ਹੋਰ ਕੁਝ ਪੇਜ਼ ਤੇ ਨਹੀਂ ਹਿਲਦਾ।
ਸੋਧ ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਸਹਾਇਕ (assistant) ਨੂੰ ਤੁਹਾਡੇ ਨਿਯਮ ਵਾਪਸ ਦੋਹਰਾਉਣ ਲਈ ਕਹੋ। ਇਸ ਨੂੰ ਪੁਸ਼ਟੀ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ ਕਿ ਕੀ ਬਦਲੇਗਾ ਅਤੇ ਕੀ ਇਕੋ ਜਿਹਾ ਰਹੇਗਾ। ਜੇ ਸੰਖੇਪ ਗਲਤ ਹੋਵੇ, ਸੋਧ ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਪ੍ਰੌਂਪਟ ਠੀਕ ਕਰੋ।
ਸਭ ਤੋਂ ਛੋਟਾ ਸੰਭਵ ਅਮਲ ਮੰਗੋ: ਕੋਈ ਰੀਫੈਕਟਰ, ਕੋਈ ਨਾਮ-ਬਦਲ, ਕੋਈ ਫਾਰਮੈਟਿੰਗ ਬਦਲ, ਕੋਈ dependency ਅੱਪਡੇਟ ਨਹੀਂ। ਤੁਸੀਂ ਇਕ ਬਦਲ ਲਈ ਪੈਸਾ ਦੇ ਰਹੇ ਹੋ, ਮਾਰਫਿੰਗ ਲਈ ਨਹੀਂ।
ਛੋਟੀ ਸਮੀਖਿਆ ਚੇਕਲਿਸਟ:
ਇਹ Koder.ai ਵਿੱਚ ਖਾਸ ਕਰਕੇ ਚੰਗਾ ਕੰਮ ਕਰਦਾ ਹੈ: freeze list Planning Mode ਵਿੱਚ ਪੇਸਟ ਕਰੋ, assistant ਨੂੰ constraints echo ਕਰਨ ਦਿਓ, ਫਿਰ ਸਭ ਤੋਂ ਛੋਟਾ patch ਬਣਵਾਓ।
ਅਕਸਰ “ਛੋਟੇ” ਸੋਧ ਇੱਕੋ ਹੀ ਕਾਰਨ ਦੇ ਨਾਲ ਗਲਤ ਹੋ ਜਾਂਦੇ ਹਨ: ਬੇਨਤੀ ਲਕੜੀ (goal) ਦੀ ਰੱਖਿਆ ਕਰਦੀ ਹੈ, ਪਰ ਵਿਹਾਰ ਦੀ ਨਹੀਂ। ਇੱਕ ਮਾਡਲ ਤੁਹਾਡੇ goal ਨੂੰ ਨਵੀਂ ਤਰੀਕੇ ਨਾਲ ਹਾਸਲ ਕਰ ਸਕਦਾ ਹੈ ਜੋ ਚੁੱਪਚਾਪ ਸਕ੍ਰੀਨਾਂ, ਲੌਜਿਕ, ਜਾਂ ਡੇਟਾ ਬਦਲ ਦੇਵੇ।
ਆਮ ਫੱਸਣ ਵਾਲੀਆਂ ਗਲਤੀਆਂ:
ਇੱਕ ਛੋਟਾ ਉਦਾਹਰਨ: ਤੁਸੀਂ ਕਹਿੰਦੇ ਹੋ “make the button more visible” ਅਤੇ ਫ੍ਰੀਜ਼ ਰੰਗ ਦੀ ਰੱਖਿਆ ਕਰਦੇ ਹੋ, ਪਰ disabled state ਫ੍ਰੀਜ਼ ਕਰਨਾ ਭੁਲ ਗਏ। ਅਪਡੇਟ ਬਟਨ ਨੂੰ ਹਮੇਸ਼ਾ ਏਨੇਬਲ ਕਰ ਸਕਦੀ ਹੈ, ਜਿਸ ਨਾਲ ਵਿਹਾਰ ਬਦਲ ਜਾਂਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਬਾਅਦਾਂ ਮਹਿਸੂਸ ਕਰਦੇ ਹੋ।
ਸਹੀ ਗੱਲ ਇਹ ਹੈ ਕਿ ਜੋ ਨਹੀਂ ਹਿਲਣਾ ਚਾਹੀਦਾ ਉਸ ਬਾਰੇ ਵਿਸ਼ੇਸ਼ ਹੋਵੋ। ਮਨਜ਼ੂਰੀ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਤੇਜ਼ ਰਿਗਰੈਸ਼ਨ ਪਾਸ ਕਰੋ:
ਜੇ ਕੋਈ ਵੀ ਭਿੰਨ ਹੋਵੇ, ਤਾਂ ਇਸ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਹਾਡੀ ਬੇਨਤੀ ਵਿੱਚ ਫ੍ਰੀਜ਼ ਦੀ ਕੋਈ ਗਲਤੀ ਸੀ, ਨਾ ਕਿ “ਖਰਾਬ ਕੋਡ”।
ਆਮ ਸੁਰੱਖਿਅਤ iteration ਇਕ ਛੋਟੀ UI polish ਹੁੰਦੀ ਹੈ ਜਿੱਥੇ ਵਰਕਫਲੋ ਨਹੀਂ ਬਦਲਣੀ ਚਾਹੀਦੀ।
ਪਰਿਦ੍ਰਸ਼: ਇੱਕ founder ਕੋਲ ਇੱਕ ਸਧਾਰਨ signup ਸਕ੍ਰੀਨ ਹੈ (Name, Email, Company size) ਅਤੇ ਇੱਕ ਪ੍ਰਾਇਮਰੀ ਬਟਨ ਜੋ ਫਾਰਮ ਸਬਮਿਟ ਕਰਦਾ ਹੈ ਅਤੇ ਯੂਜ਼ਰ ਨੂੰ ਡੈਸ਼ਬੋਰਡ 'ਤੇ ਲੈ ਜਾਂਦਾ ਹੈ।
ਸਪਸ਼ਟ ਬਦਲ ਦੀ ਮੰਗ (ਇਕ ਵਾਕ): “Rename the primary button from 'Create account' to 'Continue' and change the 'Company size' field from a free-text input to a dropdown.”
ਹੁਣ ਪੈਟਰਨ ਨੂੰ ਲਾਗੂ ਕਰੋ ਅਤੇ ਫ੍ਰੀਜ਼ ਕੀਤੇ ਜਾਣ ਵਾਲੇ ਤੱਤ:
Acceptance checks you can run in minutes:
ਇੱਕ ਚੰਗਾ assistant ਜਵਾਬ ਫ੍ਰੀਜ਼ ਆਈਟਮਾਂ ਨੂੰ ਦੁਹਰਾਉਣਾ ਚਾਹੀਦਾ ਹੈ, ਕੋਈ ਅਸਪਸ਼ਟਤਾ ਦਰਸਾਉਣੀ ਚਾਹੀਦੀ ਹੈ (ਉਦਾਹਰਨ ਲਈ: dropdown ਵਿਕਲਪਾਂ ਅਤੇ ਕੀ ਸਟੋਰ ਹੋਣਾ ਹੈ), ਅਤੇ ਫਿਰ ਸਿਰਫ ਘੱਟੋ-ਘੱਟ ਕੋਡ/UI ਬਦਲ ਦਿਖਾਉਂਦਾ ਹੋਵੇ। ਇਹ ਦੱਸਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕਿਹੜੀਆਂ ਚੀਜ਼ਾਂ ਨੂੰ ਜਾਣਬੂਝ ਕੇ ਨਹੀਂ ਛੂਹਿਆ ਗਿਆ (routing, validation logic, payload shape)।
ਇੱਕ “ਛੋਟੀ ਬਦਲ” ਮਨਜ਼ੂਰ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਤੇਜ਼ ਪਾਸ ਕਰੋ ਜੋ ਖਾਮੋਸ਼ ਡ੍ਰਿਫਟ ਲੱਭੇ। ਮਕਸਦ ਪੂਰੀ QA ਨਹੀਂ, ਬਸ ਇਹ ਪੁਸ਼ਟੀ ਕਰਨੀ ਹੈ ਕਿ ਜਿੱਥੇ ਤੁਸੀਂ "ਬਦਲ ਨਾ ਕਰੋ" ਕਿਹਾ ਸੀ, ਉੱਥੇ ਕੁਝ ਨਹੀਂ ਬਦਿਆ, ਸਿਵਾਏ ਉਸ ਇਕ ਸੋਧ ਦੇ।
ਇਹ ਚੈੱਕ ਇੱਕੋ тәрੀਕੇ ਨਾਲ ਚਲਾਓ ਹਰ ਵਾਰੀ:
ਜੇ ਕਿਸੇ ਵੀ ਫ੍ਰੀਜ਼ ਆਈਟਮ ਵਿੱਚ ਕੋਈ ਬਦਲ ਆਵੇ, ਤਾਂ ਰਿਵਰਟ ਕਰੋ, ਭਾਵੇਂ ਐਪ "ਹੁਣ ਵੀ ਕੰਮ ਕਰਦਾ" ਹੋਵੇ। ਇੱਕ ਬਦਲਾ ਲੇਬਲ, ਨਵਾਂ ਫੀਲਡ, ਜਾਂ ਥੋੜ੍ਹਾ ਜਿਹਾ ਨਿਯਮ-ਫਰਕ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਮਾਡਲ ਨੇ ਵਾਧੂ ਸੁਧਾਰ ਲਿਆਏ।
ਦੁਬਾਰਾ ਬੇਨਤੀ ਇਸ ਤਰ੍ਹਾਂ ਕਰੋ: ਇਕ ਵਾਕ ਵਿੱਚ ਇਕਲਉਤਾ ਬਦਲ ਦੁਹਰਾਓ, ਫ੍ਰੀਜ਼ ਕੀਤੇ ਫਲੋ ਅਤੇ ਸਕ੍ਰੀਨਾਂ ਨੂੰ ਨਾਮ ਦਿੱਤਾ ਹੈ, ਅਤੇ “no schema changes, no endpoint changes, no behavior changes outside X” ਸ਼ਾਮਿਲ ਕਰੋ। ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਤ ਰਹੇ ਹੋ, ਬਦਲ ਸੈੱਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ snapshot ਲੈਣਾ rollback ਨੂੰ ਇੱਕ ਕਦਮ ਵਾਲੀ ਚੀਜ਼ ਬਣਾ ਦਿੰਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ Koder.ai ਵਿੱਚ ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ ਇਹ ਪੈਟਰਨ ਇੱਕ ਆਦਤ ਬਣਾਓ: ਇੱਕ ਛੋਟਾ ਬਦਲ, ਬਾਕੀ ਸਭ ਲਾਕ, ਅਤੇ ਜੇ ਕੁਝ ਡ੍ਰਿਫਟ ਹੋਇਆ ਤਾਂ ਵਾਪਸ ਜਾਣ ਦਾ ਸਧਾਰਨ ਤਰੀਕਾ।
ਸੋਧ ਮੰਗਣ ਤੋਂ ਪਹਿਲਾਂ Planning Mode 'ਚ ਜਾਓ ਅਤੇ assistant ਨੂੰ ਤੁਹਾਡੇ ਸਕੋਪ ਨੂੰ ਸਪਸ਼ਟ ਸ਼ਬਦਾਂ 'ਚ ਦੁਹਰਾਉਣ ਲਈ ਕਹੋ। ਇਸਨੂੰ ਦੋ ਚੀਜ਼ਾਂ ਵਾਪਸ ਦੋਹਰਾਉਣੇ ਹਨ: (1) ਵਿਸ਼ੇਸ਼ ਬਦਲ, ਅਤੇ (2) ਇੱਕ ਸਪਸ਼ਟ ਫ੍ਰੀਜ਼ ਲਿਸਟ (flows, UI details, business rules)।
ਇਕ ਯੋਜਨਾ ਪ੍ਰੌਂਪਟ: “Restate my request. Then list what must not change. If anything is unclear, ask questions before editing.”
ਹਰ ਬਦਲ ਬੇਨਤੀ ਨੂੰ ਇੱਕ checkpoint ਵਾਂਗ ਟਰੀਟ ਕਰੋ। ਅਪਡੇਟ ਲਗਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ snapshot ਬਣਾਓ, ਫਿਰ ਵੈਰੀਫਾਈ ਕਰਨ ਤੋਂ ਬਾਅਦ ਦੂਜਾ snapshot ਬਣਾਓ। ਜੇ ਕੁਝ ਟੁੱਟੇ, rollback patch ਕਰਨ ਨਾਲ ਤੇਜ਼ ਹੁੰਦਾ ਹੈ।
ਸਧਾਰਨ ਵਰਕਫਲੋ:
Koder.ai React, backend (Go + PostgreSQL), ਅਤੇ mobile (Flutter) ਜਨਰੇਟ ਕਰ ਸਕਦਾ ਹੈ। ਪੈਟਰਨ ਹਰ ਕੋਡ ਬੇਸ ਲਈ ਇੱਕੋ ਰਹਿੰਦਾ ਹੈ: ਉਹ ਹਿੱਸੇ ਫ੍ਰੀਜ਼ ਕਰੋ ਜੋ ਵਿਹਾਰ ਨਿਰਧਾਰਿਤ ਕਰਦੇ ਹਨ, ਨਾ ਕਿ ਸਿਰਫ ਫਾਈਲਾਂ।
ਜੇ ਤੁਸੀਂ backend endpoint ਬਦਲ ਰਹੇ ਹੋ, request/response shape, validation rules, ਅਤੇ data writes ਫ੍ਰੀਜ਼ ਕਰੋ। ਜੇ mobile screen ਬਦਲ ਰਹੇ ਹੋ, navigation order, field defaults, ਅਤੇ error messages ਫ੍ਰੀਜ਼ ਕਰੋ। ਜੇ database logic ਬਦਲ ਰਹੇ ਹੋ, ਮਿਲਦੇ rows ਦਾ ਮਤਲਬ ਅਤੇ migrations ਸੁਰੱਖਿਅਤ ਰੱਖੋ।
ਆਪਣਾ ਟੈਮਪਲੇਟ ਕਾਪੀ ਕਰੋ, ਇੱਕ ਛੋਟੀ ਸੋਧ ਅੱਜ ਹੀ ਚਲਾਓ, ਅਤੇ ਚੈੱਕਲਿਸਟ ਨਾਲ ਪੁਸ਼ਟੀ ਕਰੋ ਪਹਿਲਾਂ ਕਿ ਤੁਸੀਂ ਸੋਧ ਮਨਜ਼ੂਰ ਕਰੋ। ਇਕ-ਇੱਕ ਬਦਲ ਕਰਦੇ ਰਹੋ।
Use it whenever you want one specific change and you care that everything else stays the same. It’s especially useful for checkout, auth, billing, or any flow where small drift creates real user issues.
Because parts of an app share components, data, and rules. A tiny UI edit can touch a reused component, which can shift layouts elsewhere, alter validation, or change API payloads without you noticing until later.
Write one clear goal, then list what must remain identical after the change. The key is to freeze behavior (flows, rules, data, integrations) and visible UI details, not just say “don’t break anything.”
Keep it short but specific: critical flows, UI/UX details that must not move, business rules, data behavior, and integrations. If you can’t name what must stay the same, the model has to guess, and guessing causes drift.
Scope it to the smallest area that still protects you. For example, freeze the checkout flow and its shared components, but don’t freeze the entire app if you’re only changing a label on one screen.
Name the journeys step-by-step and define what “done” looks like. Add the common edge cases like back button behavior, error messages, empty states, and refresh behavior so the flow stays identical in the places users notice most.
Explicitly freeze layout structure, spacing, component states (hover/disabled/loading), and all copy except the one string you’re changing. Without that, models may “clean up” styles or rewrite text in ways that change meaning or layout.
Freeze contracts: request/response shapes, validation rules, permissions, calculations, and what gets stored and when. Add one numeric example for sensitive rules like pricing so there’s no interpretation during implementation.
Ask for acceptance checks you can run fast, plus a brief diff-style summary of what changed and where. Then verify the frozen flows end-to-end, trigger at least one error state, and confirm data/integrations didn’t change.
Take a snapshot before the change, run a planning pass that repeats the scope and freeze list, then apply the smallest patch. After verifying, snapshot again so rollback is one step if anything drifted.