AI ਵਿਕਾਸ ਵਿੱਚ ਇਨਸਾਨੀ ਸਮੀਖਿਆ ਦੇ ਚੈਕਪੌਇੰਟ ਜੋ ਦਿਨਾਂ ਬਚਾਉਂਦੇ ਹਨ

ਕਿਉਂ 5-ਮਿੰਟ ਦੀਆਂ ਇਨਸਾਨੀ ਸਮੀਖਿਆਵਾਂ ਬਹੁਤ ਸਮਾਂ ਬਚਾਉਂਦੀਆਂ ਹਨ

AI-ਸਹਾਇਤ ਨਿਰਮਾਣ ਤੁਰੰਤ ਮਹਿਸੂਸ ਹੋ ਸਕਦਾ ਹੈ। ਤੁਸੀਂ ਇੱਕ ਫੀਚਰ ਵੇਖਾਉਂਦੇ ਹੋ, ਇੱਕ ਕੰਮ ਕਰਦਾ ਸਕ੍ਰੀਨ ਮਿਲਦਾ ਹੈ, ਅਤੇ ਐਪ ਲੱਗਦਾ ਹੈ ਕਿ ਤਿਆਰ ਹੈ। ਫੇਰ ਵੀ, ਛੋਟੀਆਂ ਵਿਸਥਾਰਕ ਗਲਤੀਆਂ ਅਕਸਰ ਐਜ ਕੇਸ ਪੈਦਾ ਕਰਦੀਆਂ ਹਨ: ਅਸਲੀ ਡਾਟਾ, ਅਸਲੀ ਪਰਮਿਸ਼ਨ, ਅਸਲੀ ਪ੍ਰੋਡਕਸ਼ਨ ਸੈਟਿੰਗਾਂ। ਇਹ "ਛੋਟੀਆਂ" ਗਲਤੀਆਂ ਹੀ ਉਹ ਹਨ ਜੋ ਇੱਕ ਹਫਤੇ ਦੀ ਸਫਾਈ ਵਿੱਚ ਬਦਲ ਜਾਂਦੀਆਂ ਹਨ।

ਇੱਕ ਚੈਕਪੌਇੰਟ ਇਕ ਛੋਟੀ ਇਨਸਾਨੀ ਰੋਕ ਹੈ ਜੋ ਤੁਸੀਂ ਕਿਸੇ ਬਦਲਾਅ ਨੂੰ ਮਨਜ਼ੂਰ ਜਾਂ ਸ਼ਿਪ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਲਾਉਂਦੇ ਹੋ। ਇਹ ਕੋਈ ਮੀਟਿੰਗ ਨਹੀਂ ਅਤੇ ਨਾ ਹੀ ਲੰਮਾ QA ਚੱਕਰ ਹੈ। ਇਹ ਇੱਕ ਜਾਣਬੂਝ ਕੇ ਕੀਤਾ ਗਿਆ 5-ਮਿੰਟ ਦਾ ਸਕੈਨ ਹੈ ਜਿੱਥੇ ਤੁਸੀਂ ਪੁੱਛਦੇ ਹੋ: ਜੇ ਇਹ ਗਲਤ ਹੋਵੇ ਤਾਂ ਸਭ ਤੋਂ زیادہ ਕੀ ਟੁੱਟੇਗਾ?

ਸਭ ਤੋਂ ਦਰਦਨਾਕ ਸਫਾਈਆਂ ਚਾਰ ਉੱਚ-ਖਤਰਾ ਖੇਤਰਾਂ ਤੋਂ ਆਉਂਦੀਆਂ ਹਨ:

• ਡਾਟਾ ਸਕੀਮਾ: ਗਲਤ ਟਾਈਪ, ਘੱਟ-ਪੜਤਾਲ ਵਾਲੀਆਂ ਸੀਮਾਵਾਂ, ਭ੍ਰਮਿਤ ਨਾਮ, ਗੁੰਮ ਹੋਏ ਇੰਡੈਕਸ।
• Auth ਅਤੇ ਪਰਮੀਸ਼ਨ: ਯੂਜ਼ਰ ਉਹ ਦਿਖ ਜਾਂ ਸੋਧ ਸਕਦੇ ਹਨ ਜੋ ਉਹਨਾਂ ਨੂੰ ਨਹੀਂ ਦੇਖਣੇ ਚਾਹੀਦੇ, ਜਾਂ ਐਡਮਿਨ ਆਪਣਾ ਕੰਮ ਨਹੀਂ ਕਰ ਸਕਦਾ।
• ਨਸ਼ਟ ਕਰਨ ਵਾਲੀਆਂ ਕਾਰਵਾਈਆਂ: ਮਿਟਾਉ/ਓਵਰਰਾਈਟ/ਬਲਕ ਅੱਪਡੇਟ ਜੋ ਬੜੀ ਅਸਾਨੀ ਨਾਲ ਚਲ ਰਹੇ ਹਨ ਅਤੇ ਜਿਨ੍ਹਾਂ ਦੀ ਵਾਪਸੀ ਨਹੀਂ।
• ਡਿਪਲੋਇਮੈਂਟ ਸੈਟਿੰਗਾਂ: ਗਲਤ env vars, ਮਿਲੇ-ਜੁਲੇ dev/prod ਡਾਟਾ, ਲਾਪਰਵਾਹ ਸੀਕ੍ਰੇਟ ਹੈਂਡਲਿੰਗ, ਡੋਮੇਨ ਗਲਤ ਕਨਫਿਗ।

ਇੱਕ ਛੋਟੀ ਰੋਕ ਇਸ ਲਈ ਫਾਇਦੈਮੰਦ ਹੁੰਦੀ ਹੈ ਕਿਉਂਕਿ ਇਹ ਸਮੱਸਿਆਵਾਂ ਕ੍ਰਾਸ-ਕਟਿੰਗ ਹੁੰਦੀਆਂ ਹਨ। ਇਕ ਛੋਟੀ ਸਕੀਮਾ ਗਲਤੀ APIs, ਸਕ੍ਰੀਨ, ਰਿਪੋਰਟ ਅਤੇ ਮਾਈਗ੍ਰੇਸ਼ਨਾਂ ਵਿੱਚ ਛਾਪ ਛੱਡਦੀ ਹੈ। ਇੱਕ ਪਰਮੀਸ਼ਨ ਗਲਤੀ ਸੁਰੱਖਿਆ ਘਟਨਾ ਬਣ ਸਕਦੀ ਹੈ। ਇਕ ਗਲਤ ਡਿਪਲੋਇਮੈਂਟ ਸੈਟਿੰਗ ਡਾਊਨਟਾਈਮ ਦਾ ਕਾਰਨ ਬਣ ਸਕਦੀ ਹੈ।

ਤੁਸੀਂ ਹੱਥ ਨਾਲ ਕੋਡ ਕਰੋ ਜਾਂ Koder.ai ਵਰਗੇ vibe-coding ਟੂਲ ਵਰਤੋ, ਨਿਯਮ ਇਕੋ ਹੀ ਹੈ: ਤੇਜ਼ੀ ਨਾਲ ਚੱਲੋ, ਪਰ ਜਿੱਥੇ ਨੁਕਸਾਨ ਵੱਡਾ ਹੋਵੇ ਓਥੇ ਛੋਟੇ ਗਾਰਡਰੇਲ ਲਗਾਓ।

ਇੱਕ ਸਧਾਰਣ 5-ਮਿੰਟ ਚੈਕਪੌਇੰਟ ਰੂਟੀਨ

ਚੈਕਪੌਇੰਟ ਉਹਨਾਂ ਵਿੱਚ ਸਭ ਤੋਂ ਵਧੀਆ ਕੰਮ ਕਰਦੇ ਹਨ ਜਦੋਂ ਉਹ ਪੇਸ਼ਗਿਆਨੀਯੋਗ ਹੁੰਦੇ ਹਨ। ਹਰ ਚੀਜ਼ ਦੀ ਸਮੀਖਿਆ ਨਾ ਕਰੋ। ਉਸ ਕੁਝ ਦੀ ਸਮੀਖਿਆ ਕਰੋ ਜਿਸਨੂੰ ਵਾਪਸ ਕਰਨਾ ਮਹਿੰਗਾ ਹੁੰਦਾ ਹੈ।

ਉਹ ਪਲ ਚੁਣੋ ਜੋ ਹਮੇਸ਼ਾ ਚੈਕਪੌਇੰਟ ਲੈਣ ਵਾਲੇ ਹੋਣ: ਫੀਚਰ ਪੂਰਾ ਹੋਣ ਦੇ ਬਾਅਦ, ਤੈਨਾਤ ਕਰਨ ਤੋਂ ਠੀਕ ਪਹਿਲਾਂ, ਅਤੇ ਕਿਸੇ ਵੀ ਰਿਫੈਕਟਰ ਤੋਂ ਬਾਅਦ ਜੋ ਡਾਟਾ, auth, ਬਿਲਿੰਗ ਜਾਂ ਕੋਈ ਵੀ ਪ੍ਰੋਡਕਸ਼ਨ-ਮੁਹਾਂ-ਸੰਬੰਧਤ ਚੀਜ਼ ਛੂਹਦਾ ਹੈ।

5 ਮਿੰਟ ਲਈ ਟਾਈਮਰ ਸੈੱਟ ਕਰੋ। ਜਦੋਂ ਉਹ ਖਤਮ ਹੋ ਜਾਵੇ, ਰੁਕੋ। ਜੇ ਤੁਸੀਂ ਅਸਲ ਖਤਰਾ ਲੱਭਦੇ ਹੋ, ਤਾਂ ਲੰਬੇ ਫਾਲੋਅਪ ਦਾ ਸਮਾਂ ਨਿਰਧਾਰਤ ਕਰੋ। ਜੇ ਨਹੀਂ, ਤਾਂ ਬੇਸ਼ੱਕ ਸ਼ਿਪ ਕਰੋ।

ਰੂਟੀਨ

1. ਬਦਲਾਅ ਨੂੰ ਇੱਕ ਵਾਕ ਵਿੱਚ ਨਾਮ ਦਿਓ (ਹੁਣ ਯੂਜ਼ਰ ਕੀ ਕਰ ਸਕਦੇ ਹਨ)।
2. ਬਲਾਸਟ ਰੇਡੀਅਸ ਚੈੱਕ ਕਰੋ (ਕਿਹੜੇ ਡਾਟਾ, ਰੋਲ ਅਤੇ ਵਾਤਾਵਰਨ ਇਸ ਨਾਲ ਛੂਹਦੇ ਹਨ)।
3. ਖਤਰਨਾਕ ਕਿਨਾਰਿਆਂ ਨੂੰ ਸਕੈਨ ਕਰੋ (ਸਕੀਮਾ, auth ਨਿਯਮ, ਨਸ਼ਟ ਕਰਨ ਵਾਲੀਆਂ ਕਾਰਵਾਈਆਂ, ਡਿਪਲੋਇਮੈਂਟ ਸੈਟਿੰਗਾਂ)।
4. ਇੱਕ ਰੀਐਲਟੀ ਟੈਸਟ ਚਲਾਓ (ਸਰਲ-ਤਮ flow ਜੋ ਸਮਰਥਨ ਕਰੇ ਕਿ ਇਹ ਕੰਮ ਕਰਦਾ ਹੈ)।
5. ਫੈਸਲਾ ਕਰੋ: ਅੱਗੇ ਵਧੋ, ਪ੍ਰੰਪਟ ਸੋਧੋ ਅਤੇ ਮੁੜ-ਜਨਰੇਟ ਕਰੋ, ਜਾਂ ਰੋਲਬੈਕ ਕਰੋ।

ਇੱਕ ਰਿਵਿਊਅਰ ਰੋਲ ਅਸਾਈਨ ਕਰੋ, ਭਾਵ "ਭਵਿੱਖ ਦਾ ਤੁਸੀਂ" ਵੀ ਹੋ ਸਕਦਾ ਹੈ। ਸੋਚੋ ਕਿ ਤੁਸੀਂ ਇਸਨੂੰ ਉਸ ਟੀਮਮੀਟ ਲਈ ਮਨਜ਼ੂਰ ਕਰ ਰਹੇ ਹੋ ਜਿਸਨੂੰ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਵਿਘਟਿਤ ਨਹੀਂ ਕਰ ਸਕੋਗੇ।

ਇੱਕ ਛੋਟਾ ਟੈਂਪਲੇਟ ਤੁਹਾਨੂੰ ਲਗਾਤਾਰ ਰਹਿਣ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ:

Change:
Risky areas touched:
1 quick test to run:
Decision (proceed / adjust prompt / rollback):

ਜੇ ਤੁਸੀਂ Koder.ai ਵਿੱਚ ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ ਆਖਰੀ ਕਦਮ ਨੂੰ ਸਾਬਤ ਉਦਦੇਸ਼ ਰੱਖੋ। ਸਨੈਪਸ਼ਾਟਸ ਅਤੇ ਰੋਲਬੈਕ "ਮੈਨੂੰ ਪੱਕਾ ਨਹੀਂ ਪਤਾ" ਨੂੰ ਇੱਕ ਸੁਰੱਖਿਅਤ ਫੈਸਲਾ ਬਣਾਉਂਦੇ ਹਨ।

ਸਕੀਮਾ ਸੈਨਿਟੀ: ਡਾਟਾ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਜਲਦੀ ਪਕੜੋ

ਦਿਨਾਂ ਗਵਾ ਦੇਣ ਦਾ ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਇਕ ਡੇਟਾਬੇਸ ਸਕੀਮਾ ਨੂੰ ਮਨਜ਼ੂਰ ਕਰ ਲਓ ਜੋ ਸਿਰਫ਼ "ਕਿਸੇ ਹੱਦ ਤੱਕ" ਤੁਹਾਡੇ ਮਤਲਬ ਨਾਲ ਮਿਲਦਾ ਹੋਵੇ। ਛੋਟੀਆਂ ਡਾਟਾ ਗਲਤੀਆਂ ਹਰ ਸਕ੍ਰੀਨ, API ਅਤੇ ਮਾਈਗ੍ਰੇਸ਼ਨ ਵਿੱਚ ਫੈਲਦੀਆਂ ਹਨ।

ਸ਼ੁਰੂਆਤ ਕਰੋ ਇਹ ਚੈੱਕ ਕਰਕੇ ਕਿ ਕੋਰ ਐਨਟੀਟੀਜ਼ ਅਸਲੀ ਦੁਨਿਆ ਨਾਲ ਮਿਲਦੀਆਂ ਹਨ ਕਿ ਨਹੀਂ। ਇੱਕ ਸਰਲ CRM ਨੂੰ ਆਮ ਤੌਰ 'ਤੇ Customers, Contacts, Deals ਅਤੇ Notes ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਜੇ ਤੁਸੀਂ vague ਨਾਮਾਂ ਜਿਵੇਂ "ClientItem" ਜਾਂ "Record" ਵੇਖਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਭਟਕ ਰਹੇ ਹੋ।

ਇੱਕ 5-ਮਿੰਟ ਦਾ ਸਕੀਮਾ ਸਕੈਨ:

• ਨਾਮ ਹਕੀਕਤ ਨਾਲ ਮਿਲਦੇ ਹਨ: ਟੇਬਲ ਉਹ ਚੀਜ਼ਾਂ ਦਰਸਾਉਣ ਜੋ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਗੱਲ ਕਰਦੇ ਹੋ (users, invoices, subscriptions)।
• ਨਾਮ ਪੜ੍ਹਨਯੋਗ ਅਤੇ ਸਥਿਰ ਹਨ: ਇੱਕ ਸ਼ੈਲੀ ਚੁਣੋ (created_at vs createdAt) ਅਤੇ ਠਹਿਰੋ।
• ਰਿਸ਼ਤੇ ਪੂਰੇ ਹਨ: ਇੱਕ-ਤੋਂ-ਬਹੁਤ ਜਿੱਥੇ ਲੋੜ, ਅਤੇ ਬਹੁਤ-ਤੋਂ-ਬਹੁਤ ਜਦੋਂ ਰੋਲ ਜਾਂ ਮੈਂਬਰਸ਼ਿਪ ਮਹੱਤਵਪੂਰਨ ਹੋ।
• ਕੰਸਟਰੈਂਟ ਸਾਵਧਾਨ ਹਨ: ਲਾਜ਼ਮੀ ਫੀਲਡ nullable ਨਾ ਹੋਣ, ਜ਼ਰੂਰੀ ਜ਼ਗ੍ਹਾ duplicate ਰੋਕਿਆ ਗਿਆ ਹੋਵੇ (email, invoice_number), status ਫੀਲਡਾਂ ਦਾ ਜਾਣਿਆ-ਪਛਾਣਿਆ ਸੈਟ ਹੋਵੇ।
• ਵਿਕਾਸ ਐਪ ਨੂੰ ਨਹੀਂ ਤੋੜੇਗਾ: ਆਮ ਲੁੱਕਅਪਾਂ ਤੇ ਇੰਡੈਕਸ ਹਨ, ਅਤੇ ਤੁਸੀਂ ਵੱਡੇ ਬਲਾਬ ਬਲੌਬ ਗਲਤ ਥਾਂ ਤੇ ਸਟੋਰ ਨਹੀਂ ਕਰ ਰਹੇ।

ਇੱਕ ਛੋਟਾ ਉਦਾਹਰਨ: ਇੱਕ Invoices ਟੇਬਲ ਜਿਸ ਵਿੱਚ unique invoice_number ਨਾ ਹੋਵੇ, ਡੈਮੋ ਵਿੱਚ ਠੀਕ ਲੱਗਦੀ ਹੈ। ਇੱਕ ਮਹੀਨੇ ਬਾਅਦ, ਡੁਪਲਿਕੇਟ ਆਉਂਦੇ ਹਨ, ਭੁਗਤਾਨ ਗਲਤ ਰਿਕਾਰਡ ਨੂੰ ਲਾਗੂ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਤੁਸੀਂ ਕਲੀਨਅੱਪ ਸਕ੍ਰਿਪਟਾਂ ਅਤੇ ਮਾਫ਼ੀ-ਈਮੇਲ ਲਿਖ ਰਹੇ ਹੁੰਦੇ ਹੋ। ਸਮੀਖਿਆ ਵਿੱਚ ਇਸਨੂੰ ਪਕੜਨਾ 30 ਸਕਿੰਟ ਦਾ ਫਿਕਸ ਹੈ।

ਜੇ ਤੁਸੀਂ ਸਿਰਫ ਇੱਕ ਸਵਾਲ ਪੁੱਛਦੇ ਹੋ, ਤਾਂ ਇਹ ਹੋਵੇ: ਕੀ ਤੁਸੀਂ ਸਕੀਮਾ ਨੂੰ ਦੁਨੀਆ ਦੇ ਨਵੇਂ ਟੀਮਮੀਟ ਨੂੰ ਦੋ ਮਿੰਟ ਵਿੱਚ ਸਮਝਾ ਸਕਦੇ ਹੋ? ਜੇ ਨਹੀਂ, ਤਾਂ ਉਸਨੂੰ ਤੰਗ ਕਰੋ ਪਹਿਲਾਂ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ।

Auth ਨਿਯਮ: ਕੌਣ ਕੀ ਕਰ ਸਕਦਾ ਹੈ (ਅਤੇ ਕਿਵੇਂ ਜाँचੋ)

Auth ਬੱਗ ਮਹਿੰਗੇ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਖੁਸ਼-ਰਸਤੇ ਡੈਮੋ ਉਨ੍ਹਾਂ ਨੂੰ ਛੁਪਾ ਲੈਂਦੇ ਹਨ। ਦੋ ਆਮ ਨਾਕਾਮੀਆਂ ਹਨ: "ਹਰੇਕ ਨੂੰ ਸਭ ਕੁਝ ਕਰਨ ਦੀ ਆਜ਼ਾਦੀ" ਅਤੇ "ਕੋਈ ਵੀ ਕੁਝ ਨਹੀਂ ਕਰ ਸਕਦਾ"।

ਰੋਲ ਸਾਦੇ ਸ਼ਬਦਾਂ ਵਿੱਚ ਲਿਖੋ: admin, staff, customer। ਜੇ ਐਪ ਵਿੱਚ ਟੀਮਾਂ ਹਨ, ਤਾਂ workspace member ਅਤੇ workspace owner ਵੀ ਜੋੜੋ। ਜੇ ਤੁਸੀਂ ਇੱਕ ਰੋਲ ਨੂੰ ਇੱਕ ਵਾਕ ਵਿੱਚ ਸਮਝਾ ਨਹੀਂ ਸਕਦੇ, ਤਾਂ ਨਿਯਮ ਫੈਲਣਗੇ।

ਫਿਰ ਇੱਕ ਨਿਯਮ ਲਾਗੂ ਕਰੋ: ਡਿਫਾਲਟ ਤੌਰ 'ਤੇ ਘੱਟੋ-ਘੱਟ ਪਹੁੰਚ। ਨਵੇਂ ਰੋਲਾਂ ਨੂੰ ਬਿਨਾਂ ਪਹੁੰਚ ਜਾਂ ਕੇਵਲ ਪੜ੍ਹਨ-ਕੇ-ਲਈ ਰੱਖਿਆ ਜਾਵੇ ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਬਿਲਕੁਲ ਉਹੀ ਪਹੁੰਚ ਮਿਲੇ ਜੋ ਲੋੜੀਂਦੀ ਹੈ। AI-ਜਨਰੇਟ ਕੀਤਾ ਕੋਡ ਅਕਸਰ ਪ੍ਰਭਾਵਤ ਤੌਰ 'ਤੇ ਪਰਮਿਸਿਵ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਟੈਸਟ ਪਾਸ ਕਰਵਾਉਂਦਾ ਹੈ।

ਛੇਤੀ ਤਸਦੀਕ ਕਰਨ ਲਈ, ਇੱਕ ਛੋਟਾ access matrix ਬਣਾਓ ਅਤੇ ਯੂਆਈ ਅਤੇ API ਦੋਹਾਂ ਵਿੱਚ ਅਸਲ ਤੌਰ 'ਤੇ ਟੈਸਟ ਕਰੋ:

• ਹਰ ਰੋਲ ਲਈ, ਮੁੱਖ ਆਬਜੈਕਟਾਂ 'ਤੇ create/read/update/delete ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ।
• ownership ਚੈੱਕ ਕਰੋ: ਯੂਜ਼ਰਾਂ ਨੂੰ ਸਿਰਫ਼ ਆਪਣੇ ਰਿਕਾਰਡ ਵੇਖਣੇ ਚਾਹੀਦੇ ਹਨ ਜਦ ਤੱਕ ਉਹ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਸਾਂਝੇ ਨਾ ਕੀਤੇ ਗਏ ਹੋਵਣ।
• ਇੱਕ ਅਧਕੜੀ ਕੋਸ਼ਿਸ਼ ਕਰੋ: ID ਬਦਲ ਕੇ ਦੂਜੇ ਯੂਜ਼ਰ ਦੀ ਆਇਟਮ ਖੋਲ੍ਹੋ।
• ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਸਿਰਫ਼ admin-ਵਾਲੀਆਂ ਕਾਰਵਾਈਆਂ ਹੀ admin ਤੱਕ ਸੀਮਿਤ ਹਨ (billing, exports, user management)।
• "ਛੁਪੇ" ਕਵਾਲਾਂ ਨੂੰ ਨਾ ਛੰਡੀਓ: ਲਿਸਟ ਐਂਡਪਾਇੰਟ, search, downloads।

Ownership ਚੈੱਕਾਂ ਨੂੰ ਖਾਸ ਧਿਆਨ ਦੀ ਲੋੜ ਹੈ। "ਯੂਜ਼ਰ Task ਪੜ੍ਹ ਸਕਦਾ ਹੈ" ਕਾਫ਼ੀ ਨਹੀਂ ਹੈ। ਇਹ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ: "ਯੂਜ਼ਰ Task ਪੜ੍ਹ ਸਕਦਾ ਹੈ ਜਿੱਥੇ task.ownerId == user.id" (ਜਾਂ ਯੂਜ਼ਰ workspace ਦਾ ਮੈਂਬਰ ਹੋਵੇ)।

ਐਜ ਕੇਸ ਉਹਨਾਂ ਜਗ੍ਹਾਂ ਹਨ ਜਿੱਥੇ ਲੀਕਸ ਹੁੰਦੇ ਹਨ: ਨਿਮੰਤਰਤ-ਪਰ-ਸਵੀਕਾਰ-ਨਹੀਂ ਕੀਤੇ ਗਏ ਯੂਜ਼ਰ, ਮਿਟਾਏ ਗਏ ਖਾਤੇ, ਹਟਾਏ ਗਏ ਵਰਕਸਪੇਸ ਮੈਂਬਰ ਜਿਨ੍ਹਾਂ ਦੇ ਪੁਰਾਣੇ ਸੈਸ਼ਨ ਹਨ। ਇੱਕ ਛੁੱਟਿਆ ਹੋਇਆ ਐਜ ਕੇਸ ਇੱਕ ਹਫ਼ਤੇ ਦੀ ਸਫਾਈ ਵਿੱਚ ਬਦਲ ਸਕਦਾ ਹੈ।

ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਤਦੇ ਹੋ, ਤਾਂ Асਿਸਟੈਂਟ ਨੂੰ ਬਦਲਾਅ ਮਨਜ਼ੂਰ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਰੋਲ ਅਤੇ ਇੱਕ ਐਕਸੈੱਸ ਟੇਬਲ ਆਉਟਪੁੱਟ ਕਰਨ ਲਈ ਕਹੋ, ਫਿਰ ਹਰ ਰੋਲ ਲਈ ਦੋ ਟੈਸਟ ਅਕਾਊਂਟ ਨਾਲ ਵੈਰੀਫਾਈ ਕਰੋ।

ਨਸ਼ਟ ਕਰਨ ਵਾਲੀਆਂ ਕਾਰਵਾਈਆਂ: ਅਕਸਮਾਤ ਡਾਟਾ ਲਾਸ ਤੋਂ ਬਚਾਓ

ਨਸ਼ਟ ਕਰਨ ਵਾਲੀਆਂ ਕਾਰਵਾਈਆਂ ਛੋਟੀ ਗਲਤੀ ਤੋਂ ਦਿਨਾਂ ਦੀ ਸਫਾਈ ਤੱਕ ਸਭ ਤੋਂ ਤੇਜ਼ ਰਸਤਾ ਹਨ।

ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਉਹ ਸਭ ਕੁਝ ਲਿਸਟ ਕਰੋ ਜੋ ਡਾਟਾ ਮਿਟਾ ਸਕਦਾ ਹੈ ਜਾਂ ਓਵਰਰਾਈਟ ਕਰ ਸਕਦਾ ਹੈ। ਇਹ ਸਿਰਫ਼ ਡਿਲੀਟ ਬਟਨ ਹੀ ਨਹੀਂ ਹੈ—ਇਹ reset, sync, import/replace, rebuild index, seed actions, ਅਤੇ ਵਿਸ਼ਾਲ ਐਡਮਿਨ ਟੂਲ ਵੀ ਹਨ।

ਕੁਝ ਸਾਫ਼ ਸੁਰੱਖਿਆ ਸਿਗਨਲ ਲੱਭੋ:

• ਖਤਰਨਾਕ ਕਾਰਵਾਈਆਂ ਲਈ ਸਪਸ਼ਟ ਪੁਸ਼ਟੀ (type-to-confirm ਸਭ ਤੋਂ ਵਧੀਆ)।
• ਸਕੋਪ ਕੁਦਰਤੀ ਰੱਖੋ (ਇੱਕ ਰਿਕਾਰਡ, ਇੱਕ ਯੂਜ਼ਰ, ਇੱਕ ਵਰਕਸਪੇਸ), ਨਾ ਕਿ ਆਸਾਨ "ਸਭ"।
• ਜਿਸਨੇ ਚਲਾਇਆ ਉਸਦਾ ਲਾਗ ਤੇ ਕੀ ਪ੍ਰਭਾਵ ਪਿਆ।
• ਸੇਫ਼ ਡਿਫਾਲਟ ਜਿਵੇਂ dry run, preview, ਜਾਂ archive ਬਦਲੇ delete।

ਬਹੁਤ ਸਾਰੇ ਯੂਜ਼ਰ-ਜਨਰੇਟਡ ਡਾਟਾ ਲਈ soft delete ਤਰਜੀਹ ਦਿਓ। ਇੱਕ ਸਰਲ deleted_at ਫੀਲਡ ਤੇ ਫਿਲਟਰਿੰਗ undo ਸੰਭਵ ਰੱਖਦੀ ਹੈ ਅਤੇ ਜੇ ਬੱਗ ਨਿਕਲ ਆਏ ਤਾਂ ਤੁਹਾਨੂੰ ਸਮਾਂ ਮਿਲਦਾ ਹੈ।

ਸਕੀਮਾ ਸੋਧਾਂ ਨੂੰ ਵੀ ਸੰਭਵ ਤੌਰ 'ਤੇ ਨਸ਼ਟ ਕਰਨ ਵਾਲਾ ਮਾਨੋ। ਕਾਲਮ ਡ੍ਰਾਪ ਕਰਨਾ, ਟਾਈਪ ਬਦਲਣਾ, ਅਤੇ ਕੰਸਟਰੈਂਟ ਤੀਖੇ ਕਰਨਾ ਡਾਟਾ ਗੁਆਚ ਵੀ ਕਰ ਸਕਦੇ ਹਨ। ਜੇ AI ਨੇ ਮਾਈਗ੍ਰੇਸ਼ਨ ਤਜਵੀਜ਼ ਕੀਤੀ, ਪੁੱਛੋ: ਮੌਜੂਦਾ rows ਨੂੰ ਕੀ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਅਸੀਂ ਉਨ੍ਹਾਂ ਨੂੰ ਕਿਵੇਂ بحਾਲ ਕਰਾਂਗੇ?

ਜੇ ਤੁਸੀਂ ਰੋਅਬੈਕ ਯੋਜਨਾ ਇਕ ਵਾਕ ਵਿੱਚ ਸਮਝਾ ਨਹੀਂ ਸਕਦੇ, ਤਾਂ ਨਸ਼ਟ ਕਰਨ ਵਾਲਾ ਬਦਲਾਅ ਹੁਣੇ ਹੀ ਸ਼ਿਪ ਨਾ ਕਰੋ।

ਡਿਪਲੋਇਮੈਂਟ ਸੈਟਿੰਗਾਂ: ਛੋਟੀ ਕਨਫਿਗ ਗਲਤੀਆਂ ਜੋ ਨੁਕਸਾਨ ਪਹੁੰਚਾਉਂਦੀਆਂ ਹਨ

ਅਕਸਰ ਸਫਾਈ ਦੀਆਂ ਕਹਾਣੀਆਂ ਇੱਕੋ ਹੀ ਤਰੀਕੇ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੀਆਂ ਹਨ: ਐਪ dev ਵਿੱਚ ਕੰਮ ਕਰਦਾ ਸੀ, ਪਰ ਪ੍ਰੋਡਕਸ਼ਨ ਵੱਖਰਾ ਵਿਹਾਰ ਦਿਖਾਂਦਾ ਹੈ।

ਡਿਵ ਅਤੇ ਪ੍ਰੋਡ ਨੂੰ ਰੋਕੋ ਵਜੋਂ ਵੱਖ-ਵੱਖ: ਵੱਖ ਡੈਟਾਬੇਸ, ਕੀਜ਼, ਬੱਕੇਟ ਅਤੇ ਈਮੇਲ ਪ੍ਰੋਵਾਈਡਰ। ਜੇ ਦੋਹਾਂ ਵਾਤਾਵਰਣ ਇੱਕੋ ਡੇਟਾਬੇਸ ਨੂੰ ਪוਇੰਟ ਕਰ ਰਹੇ ਹਨ, ਇੱਕ ਟੈਸਟ ਸਕ੍ਰਿਪਟ ਅਸਲ ਡਾਟਾ ਨੂੰ ਪ੍ਰਦੂਸ਼ਿਤ ਕਰ ਸਕਦੀ ਹੈ, ਅਤੇ ਇੱਕ "ਫੁਟਕਰਾ ਰੀਸੈਟ" ਸਭ ਕੁਝ ਮਿਟਾ ਸਕਦਾ ਹੈ।

ਫਿਰ ਸੀਕ੍ਰੇਟਸ ਚੈੱਕ ਕਰੋ। ਜੇ ਤੁਸੀਂ ਕਿਸੇ ਕਨਫਿਗ ਫਾਇਲ, ਪ੍ਰੰਪਟ ਜਾਂ ਕਮਿੱਟ ਸੁਨੇਹੇ ਵਿੱਚ ਕੀਜ਼ ਦੇਖਦੇ ਹੋ, ਤਦ ਮੰਨੋ ਕਿ ਉਹ ਲੀਕ ਹੋਣਗੇ। ਸੀਕ੍ਰੇਟ ਤੈਨਾਤ ਸਮੇਂ ਹੀ inject (env vars ਜਾਂ secrets manager) ਕੀਤੇ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ। ਪ੍ਰੋਡਕਸ਼ਨ ਨੂੰ ਇੱਕ ਲਾਜ਼ਮੀ ਸੀਕ੍ਰੇਟ ਨਾ ਮਿਲਣ 'ਤੇ ਸ਼ੁਰੂ ਨਾ ਹੋਣਾ ਚਾਹੀਦਾ — ਇਹ ਤਸ਼ਖੀਸ ਨਾਲ ਫੈਲ ਹੋਣ ਨਾਲੋਂ ਸਸਤਾ ਹੈ।

ਫਿਰ ਬਰਾਊਜ਼ਰ-ਸਮ੍ਹੇਤ ਸੈਟਿੰਗਾਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ: allowed origins (CORS), redirect URLs, OAuth callback URLs। ਇਹ ਆਸਾਨੀ ਨਾਲ ਥੋੜ੍ਹੇ-ਬਹੁਤ ਮਿਲਦੇ ਹਨ, ਅਤੇ ਇਸੀ ਲਈ ਤੁਸੀਂ "ਕ੍ਰਿਆ-ਸ਼ੀਲ ਲੌਗਿਨ" ਡਿਬੱਗ ਕਰ ਰਹੇ ਹੋ ਜਦੋਂ ਕੋਡ ਠੀਕ ਹੋਵੇ।

ਇੱਕ 5-ਮਿੰਟ ਡਿਪਲੋਇਮੈਂਟ ਚੈੱਕ:

• Dev ਅਤੇ prod ਵੱਖ-ਵੱਖ ਡੇਟਾਬੇਸ ਅਤੇ ਕੀਜ਼ ਵਰਤ ਰਹੇ ਹਨ।
• ਸੀਕ੍ਰੇਟ ਇੰਜੈਕਟ ਕੀਤੇ ਗਏ ਹਨ, ਹਾਰਡਕੋਡ ਨਹੀਂ।
• Origins, redirects ਅਤੇ callbacks ਅਸਲੀ ਡੋਮੇਨ ਨਾਲ ਮੇਲ ਖਾਂਦੇ ਹਨ।
• ਕਸਟਮ ਡੋਮੇਨ ਦੀਆਂ ਬੁਨਿਆਦੀ ਚੀਜ਼ਾਂ ਸਹੀ ਹਨ (DNS ਸਹੀ ਥਾਂ ਵੱਲ, HTTPS ਉਮੀਦ ਕੀਤੀ ਗਈ)।
• ਪ੍ਰੋਡਕਸ਼ਨ ਲੋਗਿੰਗ ਅਤੇ ਐਰਰ ਰਿਪੋਰਟਿੰਗ ਚਾਲੂ ਹਨ (ਬਿਨਾਂ ਸੰਵੇਦਨਸ਼ੀਲ ਡਾਟਾ ਲੌਗ ਕੀਤੇ)।

ਜੇ ਤੁਸੀਂ Koder.ai ਤੋਂ ਤੈਨਾਤ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਇਹ ਵੀ ਇੱਕ ਵਧੀਆ ਸਮਾਂ ਹੈ ਇਹ ਪੁਸ਼ਟੀ ਕਰਨ ਦਾ ਕਿ ਤੁਹਾਡੇ ਨੇ ਸਹੀ ਵਾਤਾਵਰਣ ਨੂੰ ਡਿਪਲੋਇ ਕੀਤਾ ਹੈ ਅਤੇ ਜੇ ਕੁਝ ਗਲਤ ਲੱਗੇ ਤਾਂ ਰੋਲਬੈਕ ਉਪਲਬਧ ਹੈ।

60-ਸਕਿੰਟ ਪ੍ਰੀ-ਮੇਰਜ ਚੈਕਲਿਸਟ

AI-ਜਨਰੇਟਡ ਬਦਲਾਅ ਨੂੰ ਅੰਗੀਕਾਰ ਕਰਨ ਅਤੇ ਸ਼ਿਪ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇਕ ਮਿੰਟ ਲਈ ਰੁਕੋ। ਤੁਸੀਂ ਸਟਾਈਲ ਦੀ ਸਮੀਖਿਆ ਨਹੀਂ ਕਰ ਰਹੇ — ਤੁਸੀਂ ਉਹ ਗਲਤੀਆਂ ਲੱਭ ਰਹੇ ਹੋ ਜੋ ਲੰਬੇ ਸਮੇਂ ਦੀ ਸਫਾਈ ਬਣ ਜਾਂਦੀਆਂ ਹਨ।

• ਸਕੀਮਾ: ਕੀ ਐਨਟੀਟੀਜ਼ ਮਾਨਦੰਡ ਹਨ? ਰਿਸ਼ਤੇ ਸਹੀ ਹਨ? ਕੰਸਟਰੈਂਟ ਹਨ (unique, not null)? ਵਿਕਾਸ ਕੁਿੇਰੀਜ਼ ਜਾਂ ਸਟੋਰੇਜ ਨੂੰ ਟੋੜੇਗਾ?
• Auth: ਕੀ ਇਹ default-deny ਹੈ? ਕੀ ਤੁਸੀਂ ਵਿਆਖਿਆ ਕਰ ਸਕਦੇ ਹੋ ਕਿ ਕੌਣ create/read/update/delete ਕਰ ਸਕਦਾ ਹੈ? ਕੀ ownership checks ਸਰਵਰ-ਸਾਈਡ ਤੇ ਲਾਗੂ ਹਨ (ਸਿਰਫ UI 'ਤੇ ਨਹੀਂ)?
• ਨਸ਼ਟ ਕਰਨ ਵਾਲੀਆਂ ਕਾਰਵਾਈਆਂ: ਕੀ ਅਪਰਿਵਰਤਨੀਯ ਕਾਰਵਾਈਆਂ ਲਈ ਪੁਸ਼ਟੀ ਹੈ? ਕੀ soft delete ਉਪਯੋਗ ਕੀਤਾ ਗਿਆ ਹੈ? ਕੀ ਰੋਲਬੈਕ ਯੋਜਨਾ (ਸਨੈਪਸ਼ਾਟ, ਬੈਕਅਪ, ਉਲਟ-ਮਾਈਗ੍ਰੇਸ਼ਨ) ਹੈ?
• ਡਿਪਲੋਇਮੈਂਟ: ਕੀ dev ਅਤੇ prod ਵੱਖਰੇ ਹਨ? ਕੀ ਸੀਕ੍ਰੇਟ ਕੋਡ ਤੋਂ ਬਾਹਰ ਹਨ ਅਤੇ ਲੋਗਿੰਗ ਸਹੀ ਹੈ? ਡੋਮੇਨ ਅਤੇ redirect ਸਹੀ ਹਨ?

ਇੱਕ ਉਦਾਹਰਨ: ਤੁਸੀਂ "admin delete user" ਫੀਚਰ ਮਰਜ ਕਰ ਰਹੇ ਹੋ। 60 ਸਕਿੰਟ ਵਿੱਚ ਤੁਸੀਂ ਨੋਟ ਕਰਦੇ ਹੋ ਕਿ ਬੈਕਐਂਡ ਵਿੱਚ ਕੋਈ ਰੋਲ ਚੈੱਕ ਨਹੀਂ ਹੈ — ਸਿਰਫ਼ UI ਬਟਨ ਲੁਕਿਆ ਹੋਇਆ ਹੈ। ਕੋਈ ਵੀ ਯੂਜ਼ਰ ਡਾਇਰੈਕਟਲੀ ਏਂਡਪੌਇੰਟ ਨੂੰ ਕਾਲ ਕਰ ਸਕਦਾ ਹੈ। ਇਹ ਇਕ ਕੈਚ ਤੁਹਾਨੂੰ ਇੱਕ ਘਟਨਾ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ।

ਅੰਤ ਵਿੱਚ ਇਕ ਸਵਾਲ ਪੁੱਛੋ ਜੋ ਹਕੀਕਤ ਨੂੰ ਜ਼ੋਰ ਦੇਵੇ:

ਇੱਥੇ ਇਕ ਅਸਲ ਯੂਜ਼ਰ ਸਭ ਤੋਂ ਬੁਰੀ ਤਰ੍ਹਾਂ ਕੀ ਕਰ ਸਕਦਾ ਹੈ, ਇਛਾ ਕਰਕੇ ਜਾਂ ਅਕਸਮਾਤ?

ਜੇ ਜਵਾਬ ਵਿੱਚ "ਦੂਸਰੇ ਲੋਕਾਂ ਦਾ ਡਾਟਾ ਮਿਟਾਉਣਾ", "ਪ੍ਰਾਈਵੇਟ ਰਿਕਾਰਡ ਵੇਖਣਾ" ਜਾਂ "ਪ੍ਰੋਡ ਤੋੜਨਾ" ਆਉਂਦਾ ਹੈ, ਤਾਂ ਰੁਕੋ ਅਤੇ ਬਦਲਾਅ ਨੂੰ ਤੰਗ ਕਰੋ।

ਉਦਾਹਰਨ: ਇੱਕ 5-ਮਿੰਟ ਸਮੀਖਿਆ ਜੋ ਇੱਕ ਹਫਤੇ ਦੀ ਸਫਾਈ ਰੋਕਦੀ ਹੈ

ਤੁਸੀਂ ਇੱਕ ਛੋਟੀ CRM ਬਣਾ ਰਹੇ ਹੋ ਅਤੇ AI ਟੂਲ ਨੂੰ customer ਪੇਜ 'ਤੇ "Delete customer" ਬਟਨ ਜੋੜਨ ਲਈ ਕਹਿੰਦੇ ਹੋ। ਕੁਝ ਮਿੰਟਾਂ ਵਿੱਚ ਇਹ UI, ਬੈਕਐਂਡ ਏਂਡਪੌਇੰਟ ਅਤੇ ਰਿਲੇਟਿਡ ਰਿਕਾਰਡ ਹਟਾਉਣ ਲਈ ਡੇਟਾਬੇਸ ਬਦਲਾਅ ਜਨਰੇਟ ਕਰ ਦਿੰਦਾ ਹੈ।

ਸਭ ਕੁਝ ਚੱਲਦਾ ਪਤਾ ਲੱਗਦਾ ਹੈ: ਬਟਨ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ, ਰਿਕਵੈਸਟ 200 ਵਾਪਸ ਕਰਦਾ ਹੈ, ਅਤੇ customer ਲਿਸਟ ਤੋਂ ਗਾਇਬ ਹੋ ਜਾਂਦਾ ਹੈ। ਬਹੁਤੇ ਟੀਮਾਂ ਅੱਗੇ ਵਧਦੀਆਂ ਹਨ।

ਇੱਕ 5-ਮਿੰਟ ਸਮੀਖਿਆ ਦੋ ਸਮੱਸਿਆਵਾਂ ਫੜ ਲੈਂਦੀ ਹੈ:

1. ਡੇਟਾਬੇਸ ਬਦਲਾਅ cascade delete ਵਰਤਦਾ ਹੈ ਜੋ invoices ਅਤੇ activity logs ਨੂੰ ਵੀ ਹਟਾ ਦਿੰਦਾ ਹੈ। ਟੈਸਟ ਡਾਟਾ ਲਈ ਠੀਕ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਅਸਲ CRM ਵਿੱਚ ਇਹ ਰਿਪੋਰਟਿੰਗ, ਆਡਿਟ ਅਤੇ ਗਾਹਕ ਇਤਿਹਾਸ ਨੂੰ ਤਬਾਹ ਕਰ ਸਕਦਾ ਹੈ।
2. ਏਂਡਪੌਇੰਟ ਸਿਰਫ਼ ਇਹ ਚੈੱਕ ਕਰਦਾ ਹੈ ਕਿ ਯੂਜ਼ਰ ਸਾਈਨ ਇਨ ਹੈ, ਨਾ ਕਿ ਉਹ admin ਰੋਲ ਹੈ। ਕੋਈ ਵੀ ਸਟਾਫ ਮੈਂਬਰ ਕਿਸੇ ਵੀ customer ਨੂੰ ਹਟਾ ਸਕਦਾ ਹੈ।

ਅਮਲ ਵਿੱਚ ਇੱਕ ਛੋਟੀ ਸਮੀਖਿਆ:

• ਇੱਕ non-admin ਟੈਸਟ ਯੂਜ਼ਰ ਦੇ ਤੌਰ 'ਤੇ ਬਟਨ ਤੇ ਕਲਿੱਕ ਕਰੋ ਅਤੇ ਪੱਕਾ ਕਰੋ ਕਿ ਇਹ ਫੇਲ ਹੁੰਦਾ ਹੈ।
• ਏਂਡਪੌਇੰਟ ਦੀ ਜਾਂਚ ਕਰੋ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਇਹ ਉਹਨਾਂ ਯੂਜ਼ਰਾਂ ਨੂੰ ਰੱਦ ਕਰਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਕੋਲ ਠੀਕ ਰੋਲ ਨਹੀਂ ਹੈ।
• ਸਕੀਮਾ ਨੂੰ ਸਕੈਨ ਕਰੋ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ invoices, notes ਅਤੇ logs ਨੂੰ ਕੀ ਹੁੰਦਾ ਹੈ।
• UI ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਪੁਸ਼ਟੀ ਮੰਗਦਾ ਹੈ ਅਤੇ ਦਿਖਾਉਂਦਾ ਹੈ ਕੀ ਮਿਟਾਇਆ ਜਾਵੇਗਾ।
• ਇਹ ਟੈਸਟ ਕਰਦੇ ਸਮੇਂ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਤੁਸੀਂ ਸਹੀ ਡੇਟਾਬੇਸ ਤੇ ਟੈਸਟ ਕਰ ਰਹੇ ਹੋ।

ਇੱਕ ਪ੍ਰੰਪਟ ਸੋਧ ਇਸਨੂੰ ਸ਼ਿਪ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਠੀਕ ਕਰ ਦਿੰਦੀ:

"Make delete customer a soft delete. Keep invoices and logs. Only admins can delete. Add a confirmation step that requires typing DELETE. Return a clear error message when unauthorized."

ਫਿਰ ਇਸਨੂੰ ਮੁੜ ਟੁੱਟਣ ਤੋਂ ਬਚਾਉਣ ਲਈ ਪ੍ਰੋਜੈਕਟ ਨੋਟਸ ਵਿੱਚ ਤਿੰਨ ਚੀਜ਼ਾਂ ਦਰਜ ਕਰੋ: delete ਨਿਯਮ (soft vs hard), permission ਲੋੜ (ਕੌਣ ਹਟਾ ਸਕਦਾ ਹੈ), ਅਤੇ ਉਮੀਂਦਿਤ ਸਾਈਡ-ਇਫੈਕਟਸ (ਕਿਹੜਾ ਸੰਬੰਧਤ ਡਾਟਾ ਰਹਿੰਦਾ ਹੈ)।

ਪ੍ਰੰਪਟਸ ਜੋ ਸਪਸ਼ਟਤਾ ਮੰਗਦੇ ਹਨ ਪਹਿਲਾਂ ਕਿ ਤੁਸੀਂ ਬਦਲਾਅ ਮਨਜ਼ੂਰ ਕਰੋ

AI ਆਊਟਪੁੱਟ ਆਤਮ ਵਿਸ਼ਵਾਸ ਨਾਲ ਸੁਣਦਾ ਹੈ ਪਰ ਅਨੁਮਾਨ ਨੂੰ ਛੁਪਾ ਸਕਦਾ ਹੈ। ਲਕੜੀ ਦਾ ਮਕਸਦ ਉਹਨਾਂ ਅਨੁਮਾਨਾਂ ਨੂੰ ਦਿੱਖਾਉਣਾ ਹੈ।

ਇਹ ਸ਼ਬਦ ਜੋ ਅਗਲੇ ਸਵਾਲ ਖੜੇ ਕਰਨ ਚਾਹੀਦੇ ਹਨ: “assume”, “default”, “simple”, “should”, “usually”. ਉਹ ਅਕਸਰ ਮਤਲਬ ਰੱਖਦੇ ਹਨ "ਮੈਂ ਕੁਝ ਚੁਣਿਆ ਬਿਨਾਂ ਪੁਸ਼ਟੀ ਕਰਵਾਏ"।

ਉਪਯੋਗੀ ਪ੍ਰੰਪਟ ਪੁਨਰੂਪ:

“Rewrite your proposal as acceptance criteria. Include: required fields, error states, and 5 edge cases. If you made assumptions, list them and ask me to confirm.”

ਦੋ ਹੋਰ ਪ੍ਰੰਪਟ ਜੋ ਜੋਖਮ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਬਾਹਰ ਲੈਂਦੇ ਹਨ:

• “Show the data model changes as a before/after table. For each field: type, nullability, default, and migration risk.”
• “List all destructive operations you introduced (drop table/column, delete endpoints, cascade rules). For each, show how to undo it and what data is lost.”

Auth ਲਈ:

“Show roles and permissions for each API route and UI action. For every role: allowed actions, denied actions, and one example request that should fail.”

ਫੈਸਲਾ ਕਰੋ ਕਿ ਕੀ ਚੀਜ਼ਾਂ ਹਮੇਸ਼ਾ ਮਨੁੱਖੀ-ਦੁਆਰਾ ਵੈਰੀਫਾਇ ਕੀਤੀਆਂ ਜਾਣ, ਅਤੇ ਇਸਨੂੰ ਛੋਟਾ ਰੱਖੋ:

• Auth ਨਿਯਮ ਅਤੇ ਐਡਮਿਨ ਕਾਰਵਾਈਆਂ
• Delete, cascade, irreversible migrations
• ਵਾਤਾਵਰਣ ਅਤੇ ਡਿਪਲੋਇਮੈਂਟ ਸੈਟਿੰਗਾਂ (prod vs staging)
• ਭੁਗਤਾਨ, ਈਮੇਲ, ਅਤੇ ਯੂਜ਼ਰ-ਡਾਟਾ ਫਲੋ
• ਰੋਲਬੈਕ ਯੋਜਨਾ (ਸਨੈਪਸ਼ਾਟ ਜਾਂ ਰਿਲੀਜ਼ ਪੁਆਇੰਟ)

ਆਮ ਗਲਤੀਆਂ ਜੋ ਸਫਾਈ ਨੂੰ ਦਿਨਾਂ ਲਈ ਲੰਮਾ ਕਰ ਦਿੰਦੀਆਂ ਹਨ

ਜ਼ਿਆਦਾਤਰ ਲੰਬੀਆਂ ਸਫਾਈਆਂ ਇਕੋ ਹੀ ਛੋਟੀ ਚੋਣ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੀਆਂ ਹਨ: ਆਊੱਟਪੁੱਟ 'ਤੇ ਭਰੋਸਾ ਕਰਨਾ ਕਿਉਂਕਿ ਉਹ "ਹੁਣ" ਕੰਮ ਕਰਦਾ ਹੈ।

“ਇਹ ਮੇਰੀ ਮਸ਼ੀਨ 'ਤੇ ਚੱਲਦਾ ਹੈ" ਕਲਾਸਿਕ ਫੰਦੇ ਹੈ। ਇੱਕ ਫੀਚਰ ਲੋਕਲ ਟੈਸਟਾਂ ਪਾਸ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਫਿਰ ਵੀ ਅਸਲ ਡਾਟਾ ਸਾਈਜ਼ਾਂ, ਅਸਲ ਪਰਮਿਸ਼ਨਾਂ, ਜਾਂ ਥੋੜ੍ਹਾ ਵੱਖਰਾ ਵਾਤਾਵਰਣ ਹੋਣ 'ਤੇ ਫੇਲ ਹੋ ਸਕਦਾ ਹੈ। ਇਸ ਨੂੰ ਠੀਕ ਕਰਨਾ ਐਮਰਜੈਂਸੀ ਪੈਚਾਂ ਦਾ ਲਿਕੜਾ ਬਣ ਜਾਂਦਾ ਹੈ।

ਸਕੀਮਾ ਡ੍ਰਿਫਟ ਇਕ ਹੋਰ ਮੈਗਨੇਟ ਹੈ। ਜਦੋਂ ਟੇਬਲਾਂ ਤਬਦੀਲ ਹੁੰਦੀਆਂ ਹਨ ਬਿਨਾਂ ਸਪਸ਼ਟ ਨਾਂਵਾਂ, ਕੰਸਟਰੈਂਟਾਂ ਅਤੇ ਡਿਫਾਲਟਾਂ ਦੇ, ਤੁਸੀਂ ਇੱਕ-ਆਫ ਮਾਈਗ੍ਰੇਸ਼ਨਾਂ ਅਤੇ ਅਜੀਬ ਵਰਕਅਰਾਊਂਡਜ਼ ਨਾਲ ਖਤਮ ਹੋ ਜਾਂਦੇ ਹੋ। ਬਾਅਦ ਵਿੱਚ ਕੋਈ ਪੁੱਛਦਾ ਹੈ, "status ਦਾ ਕੀ ਮਤਲਬ ਹੈ?" ਅਤੇ ਕੋਈ ਜਵਾਬ ਨਹੀਂ ਹੁੰਦਾ।

Auth ਨੂੰ ਆਖਿਰ ਵਿੱਚ ਜੋੜਨ ਨਾਲ ਦਰਦ ਹੋਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਧਾਰਨਾਵਾਂ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਹਰ ਚੀਜ਼ ਨੂੰ ਐਸਾ ਬਣਾਉਂਦੇ ਹੋ ਜਿਵੇਂ ਹਰ ਯੂਜ਼ਰ ਸਭ ਕੁਝ ਕਰ ਸਕਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਹੱਫ਼ਤਿਆਂ ਤਕ ਦੇ ਨਾਲ-ਨਾਲ ਰੰਦਿਆਂ ਦੀ ਭਰਾਈ ਕਰੋਗੇ।

ਨਸ਼ਟ ਕਰਨ ਵਾਲੀਆਂ ਕਾਰਵਾਈਆਂ ਸਭ ਤੋਂ ਤੇਜ਼ ਤਬਾਹੀਆਂ ਕਰਦੀਆਂ ਹਨ। "Delete project" ਜਾਂ "reset database" ਅਸਾਨੀ ਨਾਲ ਲਾਗੂ ਹੋ ਜਾਂਦੇ ਹਨ ਅਤੇ ਬਿਨਾਂ soft delete, snapshots ਜਾਂ ਰੋਲਬੈਕ ਯੋਜਨਾ ਦੇ ਅਸਾਨੀ ਨਾਲ ਅਫਸੋਸ ਦਾ ਕਾਰਨ ਬਣ ਜਾਂਦੇ ਹਨ।

ਕੁਝ ਮੁੜ-ਮੁੜ ਉਤਪੰਨ ਹੋਣ ਵਾਲੇ ਕਾਰਨ ਜਿਹੜੇ ਬਹੁ-ਦਿਨੀ ਸਫਾਈ ਦਾ ਕਾਰਨ ਬਣਦੇ ਹਨ:

• ਕੰਸਟਰੈਂਟਾਂ (unique, not null, foreign keys) ਤੋਂ ਬਿਨਾਂ ਸਕੀਮਾ ਸੋਧ
• UI-ਕੇਵਲ ਪਰਮੀਸ਼ਨ ਨਿਯਮ, ਸਰਵਰ-ਸਾਈਡ ਚੈਕ ਨਾ ਹੋਣਾ
• ਪੁਸ਼ਟੀ ਅਤੇ ਰੀਕਵਰੀ ਤੋਂ ਬਿਨਾਂ ਡਿਲੀਟ ਏਂਡਪਾਇੰਟ
• staging ਅਤੇ production ਨੂੰ "ਲਗਭਗ ਇੱਕੋ" ਮਾਨਣਾ
• ਕਿਸਨੇ ਕੀ ਬਦਲਾਅ ਕੀਤਾ, ਇਸ ਦੀ ਕੋਈ ਰਿਕਾਰਡਿੰਗ ਨਾ ਹੋਣਾ

ਅੱਗੇ ਦੇ ਕਦਮ: ਚੈਕਪੌਇੰਟਾਂ ਨੂੰ ਆਪਣੀ ਨਿਰਮਾਣ ਵਿਧੀ ਦਾ ਹਿੱਸਾ ਬਣਾਓ

ਚੈਕਪੌਇੰਟਾਂ ਨੂੰ ਜ਼ਿੰਦਾ ਰੱਖਣ ਦਾ ਸਭ ਤੋਂ ਆਸਾਨ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ ਉਹਨਾਂ ਨੂੰ ਉਹਨਾਂ ਪਲਾਂ ਨਾਲ ਜੋੜੋ ਜਿਹੜੇ ਤੁਹਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਹਨ: ਇੱਕ ਫੀਚਰ ਸ਼ੁਰੂ ਕਰਨਾ, ਉਸਨੂੰ ਮਰਜ ਕਰਨਾ, ਤੈਨਾਤ ਕਰਨਾ, ਅਤੇ ਤਸਦੀਕ ਕਰਨਾ।

ਇੱਕ ਹਲਕਾ ਰਿਥਮ:

• ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ: ਡਾਟਾ ਰੂਪ (ਟੇਬਲ, ਮੁੱਖ ਫੀਲਡ) ਅਤੇ ਰੋਲ (ਕੌਣ read/create/update/delete ਕਰੇਗਾ) 'ਤੇ ਸਹਿਮਤੀ ਕਰੋ।
• ਮਰਜ ਤੋਂ ਪਹਿਲਾਂ: auth, ਨਸ਼ਟ ਕਰਨ ਵਾਲੀਆਂ ਕਾਰਵਾਈਆਂ, ਅਤੇ ਕੋਈ ਵੀ ਪ੍ਰੋਡਕਸ਼ਨ ਡਾਟਾ ਨੂੰ ਛੂਹਣ ਵਾਲੀ ਚੀਜ਼ ਲਈ 60-ਸਕਿੰਟ ਪਾਸ ਕਰੋ।
• ਡਿਪਲੋਇ ਤੋਂ ਪਹਿਲਾਂ: ਵਾਤਾਵਰਣ ਸੈਟਿੰਗਾਂ (ਡੋਮੇਨ, ਸੀਕ੍ਰੇਟ, ਈਮੇਲ, ਸਟੋਰੇਜ, ਰੀਜਨ) ਨਿਸ਼ਚਿਤ ਕਰੋ ਕਿ ਲਕੜੀ ਨਾਲ ਮੇਲ ਖਾਂਦੀਆਂ ਹਨ।
• ਡਿਪਲੋਇ ਤੋਂ ਬਾਅਦ: ਇੱਕ ਅਸਲ ਯੂਜ਼ਰ ਫਲੋ ਨੂੰ end-to-end ਚਲਾਓ।

ਜੇ ਤੁਸੀਂ Koder.ai 'ਤੇ ਕੰਮ ਕਰਦੇ ਹੋ, ਤਾਂ ਇਸ ਦੀ planning mode "ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ" ਚੈਕਪੌਇੰਟ ਵਜੋਂ ਕੰਮ ਕਰ ਸਕਦੀ ਹੈ: ਫੈਸਲਿਆਂ ਨੂੰ ਲਿਖੋ ਜਿਵੇਂ "orders signed-in users ਬਣਾਉਣ ਲਾ ਸਕਦੇ ਹਨ, ਪਰ ਸਿਰਫ਼ admins status ਬਦਲ ਸਕਦੇ ਹਨ" ਪਹਿਲਾਂ ਹੀ, ਤਬ ਜਨਰੇਟਿੰਗ ਕਰੋ। ਸਨੈਪਸ਼ਾਟ ਅਤੇ ਰੋਲਬੈਕ ਵੀ ਇਹਨਾਂ ਨੂੰ ਮੁੜ-ਜਨਰੇਟ ਕਰਨ ਸਮੇਂ ਸੁਰੱਖਿਅਤ ਬਣਾਉਂਦੇ ਹਨ।

ਪੰਜ ਮਿੰਟ ਹਰ ਚੀਜ਼ ਨਹੀਂ ਪਕੜੇਗਾ। ਪਰ ਇਹ ਮਹਿੰਗੀਆਂ ਗਲਤੀਆਂ ਨੂੰ ਯਕੀਨੀ ਤੌਰ 'ਤੇ ਸੇਵ ਕਰਦਾ ਹੈ ਜਦੋਂ ਉਹ ਅਜੇ ਵੀ ਸਸਤੇ ਹਨ।