Claude Code ਗ੍ਰੀਨਫੀਲਡ ਵਰਕਫਲੋ: ਖਾਲੀ ਰਿਪੋ ਤੋਂ ਪਹਿਲੀ ਸਲਾਈਸ ਤੱਕ

ਇੱਕ greenfield ਸ਼ੁਰੂਆਤ ਦੇ ਨਾਲ ਤੁਸੀਂ ਕੀ ਟਾਲਣਾ ਚਾਹੁੰਦੇ ਹੋ

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

ਕੁਝ ਜ਼ਰੂਰੀ ਫੇਲਹੋਈਆਂ ਵਾਰ-ਵਾਰ ਨਜ਼ਰ ਆਉਂਦੀਆਂ ਹਨ:

• ਕੋਡ ਜੋ “ਮੇਰੀ ਮਸ਼ੀਨ 'ਤੇ ਚੱਲਦਾ ਹੈ” ਕਿਉਂਕਿ ਸੈਟਅਪ ਕਿਸੇ ਦੇ ਯਾਦ ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ, ਸਕ੍ਰਿਪਟਾਂ ਵਿੱਚ ਨਹੀਂ।
• ਫੋਲਡਰ ਟ੍ਰੀ ਜੋ ਉਸ ਕ੍ਰਮ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਚੀਜ਼ਾਂ ਬਣਾਈਆਂ ਗਈਆਂ, ਨਾ ਕਿ ਇਹ ਕਿ ਐਪ ਕਿਵੇਂ ਵਧੇਗੀ।
• ਇੱਕ ਲੂਪ ਜਿੱਥੇ ਹਰ ਨਵਾਂ ਪ੍ਰਾਂਪਟ ਪਿਛਲੇ ਚੋਣਾਂ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖ ਦਿੰਦਾ ਹੈ, ਇਸ ਲਈ ਕੁਝ ਵੀ ਸਥਿਰ ਨਹੀਂ ਬਣਦਾ।

ਸ਼ੁਰੂਆਤੀ ਫੈਸਲੇ ਮੁੜ ਕਰਨਾ ਦਰਦਨਾਕ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਹਰ ਚੀਜ਼ ਉਨ੍ਹਾਂ ਦੇ ਊਪਰ ਢੁੱਕ ਜਾਂਦੀ ਹੈ। ਇੱਕ ਗੁੰਝਲਦਾਰ ਬਣਤਰ ਖੁਦ-ਬ-ਖੁਦ ਮਜ਼ਬੂਤ ਹੁੰਦੀ ਰਹਿੰਦੀ ਹੈ। ਇੱਕ ਮੈਨੂਅਲ ਬਿਲਡ ਦਸ ਵੱਖ-ਵੱਖ ਸੈਟਅਪ ਬਣ ਜਾਂਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਸ਼ੁਰੂ ਵਿਚ ਇੱਕ ਸਧਾਰਨ dev ਕਮਾਂਡ ਲਾਕ ਨਾ ਕਰੋ, ਤਾਂ ਤੁਸੀਂ ਨਹੀਂ ਪਤਾ ਲਾ ਸਕੋਗੇ ਕਿ ਕੋਈ ਬਦਲਾਅ ਐਪ ਨੂੰ ਤੋੜਿਆ ਹੈ ਜਾਂ ਸਿਰਫ਼ ਵਾਤਾਵਰਣ ਨੂੰ ਤੋੜਿਆ ਹੈ।

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

“ਵਰਟੀਕਲ ਸਲਾਈਸ” ਸਭ ਤੋਂ ਛੋਟੀ end-to-end ਫੀਚਰ ਹੁੰਦੀ ਹੈ ਜੋ ਦਰਸਾਉਂਦੀ ਹੈ ਕਿ ਤੁਹਾਡੀ ਐਪ ਅਸਲੀ ਹੈ। ਇਹ ਨਾ ਤਾਂ ਇੱਕ UI ਮੌਕ ਹੈ, ਨਾ ਹੀ ਸਿਰਫ਼ ਇੱਕ ਡੇਟਾਬੇਸ ਟੇਬਲ। ਇਹ ਸਿਸਟਮ ਦੇ ਹੋਰ-ਹੋਰ ਹਿੱਸਿਆਂ ਵਿੱਚੋਂ ਇੱਕ ਤਿੱਖੀ ਲਾਈਨ ਹੁੰਦੀ ਹੈ—ਜਿਵੇਂ ਕਿਸੇ ਪੇਜ਼ ਨਾਲ ਫਾਰਮ, ਇੱਕ API ਏਂਡਪੌਇੰਟ ਜੋ ਡੇਟਾ ਸੇਵ ਕਰਦਾ ਹੈ, ਇੱਕ ਡੇਟਾਬੇਸ ਲਿਖਤ ਅਤੇ ਪੜ੍ਹਾਈ, ਅਤੇ ਪੇਜ਼ 'ਤੇ ਇੱਕ ਦਿਖਾਈ ਦੇਣ ਵਾਲਾ ਨਤੀਜਾ।

ਜੇ ਤੁਸੀਂ ਇੱਕ ਕਮਾਂਡ ਨਾਲ ਐਪ ਚਲਾ ਸਕਦੇ ਹੋ ਅਤੇ ਇੱਕ ਵਰਟੀਕਲ ਸਲਾਈਸ ਭੇਜ ਸਕਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਅਜਿਹਾ ਬੇਸ ਹੁੰਦਾ ਹੈ ਜਿਸ 'ਤੇ ਤੁਸੀਂ ਅਨੁਮਾਨ ਲਗਾਏ ਬਿਨਾਂ iterate ਕਰ ਸਕਦੇ ਹੋ।

ਕੁਝ ਵੀ ਜਨਰੇਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਪਹਿਲੀ ਸਲਾਈਸ ਨਿਰਧਾਰਤ ਕਰੋ

ਇੱਕ ਸਪਸ਼ਟ ਪਹਿਲੀ ਸਲਾਈਸ ਤੁਹਾਡੇ ਰਿਪੋ ਨੂੰ ਸਾਫ ਰੱਖਦੀ ਹੈ ਅਤੇ ਤੁਹਾਡੇ ਪ੍ਰਾਂਪਟਾਂ ਨੂੰ ਕੇਂਦ੍ਰਿਤ ਰੱਖਦੀ ਹੈ। ਇਹ ਉਹ ਸਮਾਂ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਨਿਰਧਾਰਤ ਕਰੋ ਕਿ ਤੁਸੀਂ end-to-end ਕੀ ਡੈਮੋ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਨਾ ਕਿ ਜੋ ਤੁਸੀਂ ਉਮੀਦ ਕਰਦੇ ਹੋ ਕਿ ਪੂਰਾ ਉਤਪਾਦ ਕਹਾਂ ਤੱਕ ਪਹੁੰਚੇਗਾ।

ਉਸ ਸਭ ਤੋਂ ਛੋਟੀ ਯੂਜ਼ਰ ਸਟੋਰੀ ਨੂੰ ਚੁਣੋ ਜੋ ਸਾਬਤ ਕਰੇ ਕਿ ਐਪ ਸਾਰਾ ਰਸਤਾ ਕੰਮ ਕਰਦੀ ਹੈ। ਇੱਕ ਚੰਗੀ ਸਲਾਈਸ UI, ਡੇਟਾ ਅਤੇ ਇੱਕ ਅਸਲ ਐਕਸ਼ਨ ਨੂੰ ਛੂੰਹਦੀ ਹੈ। ਉਦਾਹਰਨ: “ਇੱਕ ਯੂਜ਼ਰ ਵਜੋਂ, ਮੈਂ ਇੱਕ ਟਾਸਕ ਜੋੜ ਸਕਦਾ/ਸਕਦੀ ਹਾਂ ਅਤੇ ਰੀਫ੍ਰੇਸ਼ ਤੋਂ ਬਾਅਦ ਇਹ ਲਿਸਟ ਵਿੱਚ ਵੇਖ ਸਕਦਾ/ਸਕਦੀ ਹਾਂ।” ਇਹ ਛੋਟੀ ਹੈ, ਪਰ ਇਹ ਰਾਊਟਿੰਗ, ਵੈਲਿਡੇਸ਼ਨ, ਸਟੋਰੇਜ ਅਤੇ ਇੱਕ ਬੁਨਿਆਦੀ ਸਕਰੀਨ ਨੂੰ ਮਜਬੂਰ ਕਰਦੀ ਹੈ।

ਹਫ਼ਤਾ 1 ਲਈ ਇੱਕ ਟਾਰਗੇਟ ਪਲੇਟਫਾਰਮ ਚੁਣੋ ਅਤੇ ਉਸ 'ਤੇ ਟਿਕੇ ਰਹੋ। ਜੇ ਤੁਸੀਂ ਵੈੱਬ ਨਾਲ ਸ਼ੁਰੂ ਕਰਦੇ ਹੋ, ਤਾਂ ਸਿਰਫ਼ ਵੈੱਬ ਕਰੋ। “ਸਿਰਫ਼ ਇਨ ਕੇਸ” ਲਈ ਮੋਬਾਈਲ ਸਕ੍ਰੀਨ ਨਾ ਜੋੜੋ। ਭਾਵੇਂ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ Koder.ai ਵਰਗਾ ਪਲੇਟਫਾਰਮ ਵਰਤਣਾ ਯੋਜਨਾ ਬਣਾਉਂਦੇ ਹੋ, ਪਹਿਲੀ ਸਲਾਈਸ ਇੱਕ ਲੇਨ ਵਿੱਚ ਰਹੇ ਤਾਂ ਬਿਹਤਰ ਨਤੀਜੇ ਮਿਲਦੇ ਹਨ (React web, ਜਾਂ Go API, ਜਾਂ Flutter)।

"ਹਫ਼ਤਾ 1" ਲਈ "ਹੋ ਗਿਆ" ਦਾ ਮਤਲਬ ਸਧਾਰਨ ਲਫ਼ਜ਼ਾਂ ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ:

• ਇੱਕ ਤਾਜ਼ਾ ਕਲੋਨ ਤੋਂ ਇੱਕ ਕਮਾਂਡ ਨਾਲ ਲੋਕਲ ਰਨ ਹੁੰਦੀ ਹੈ
• ਇੱਕ ਕੰਮ ਕਰ ਰਹੀ ਫੀਚਰ ਜੋ ਤੁਸੀਂ end-to-end ਕਲਿੱਕ ਕਰ ਸਕਦੇ ਹੋ
• ਐਰਰ ਸੂਚਨਾ ਮਨੁੱਖੀ ਲਹਜ਼ੇ ਵਿੱਚ ਦਿਖਾਈ ਦੇਵੇ (ਸਟੈਕ ਟ੍ਰੇਸ ਨਹੀਂ)
• ਡੇਟਾ ਕਿਤੇ ਸਧਾਰਨ ਢੰਗ ਨਾਲ ਪੈਰਸਿਸਟ ਹੁੰਦਾ ਹੈ (ਇੱਕ ਲੋਕਲ ਡੇਟਾਬੇਸ ਵੀ ਚੱਲਦਾ ਹੈ)

ਫਿਰ ਤਿੰਨ ਨਾ-ਉਦੇਸ਼ ਲਿਖੋ ਜੋ ਸਕੋਪ ਦੀ ਰੱਖਿਆ ਕਰਨ। ਉਦਾਹਰਨ: ਕੋਈ auth ਨਹੀਂ, ਕੋਈ theme ਸਿਸਟਮ ਨਹੀਂ, ਕੋਈ background jobs ਨਹੀਂ।

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

ਕੁਝ ਪਹਿਲੇ ਫੈਸਲੇ ਜੋ ਦੁਬਾਰਤ ਰੋਕਣਗੇ

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

ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਐਪ ਦਾ ਆਕਾਰ ਨਿਰਧਾਰਤ ਕਰੋ। ਜੇ ਤੁਹਾਨੂੰ ਸੱਚਮੁੱਚ ਬ੍ਰਾਊਜ਼ਰ UI ਅਤੇ ਇੱਕ ਬੈਕਐਂਡ ਲੋੜੀ ਹੈ, ਤਾਂ ਦੁਇਣ ਹਿੱਸਿਆਂ (frontend + API) ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ contracts ਲਈ ਇਕ ਸਾਂਝੀ ਥਾਂ ਰੱਖੋ (API types ਜਾਂ ਸਧਾਰਨ schema)। ਜੇ ਐਪ ਇੱਕ single server-rendered ਵੈੱਬ ਐਪ ਹੋ ਸਕਦੀ ਹੈ, ਤਾਂ ਇੱਕ ਕੋਡਬੇਸ ਰੱਖੋ ਤਾਂ ਕਿ ਲੋਕਲ ਡਿਵੈਲਪਮੈਂਟ ਸਧਾਰਨ ਰਹੇ।

ਅਗਲਾ, configuration ਨਿਯਮਾਂ 'ਤੇ ਰਾਖੀ ਕਰੋ। ਇੱਕ ਲੋਕਲ env ਫਾਇਲ ਵਰਤੋ, ਇਸਨੂੰ git ਤੋਂ ਬਾਹਰ ਰੱਖੋ, ਪਰ ਇੱਕ ਟੈਮਪਲੇਟ commit ਕਰੋ (ਉਦਾਹਰਨ ਲਈ .env.example) ਜਿਸ ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਪਲੇਸਹੋਲਡਰ ਅਤੇ ਛੋਟੀ ਟਿੱਪਣੀਆਂ ਹੋਣ। ਇਹ onboarding ਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ secrets ਲੀਕ ਹੋਣ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ।

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

ਸਧਾਰਨ ਸ਼ੁਰੂਆਤੀ ਫੈਸਲਿਆਂ ਦਾ ਇੱਕ ਸੈੱਟ:

• ਐਪ ਆਕਾਰ: single app ਜਾਂ frontend + API
• ਕਾਨਫਿਗ: .env ਲੋਕਲ, .env.example committed
• ਪੋਰਟ: web ਲਈ ਇੱਕ, API ਲਈ ਇੱਕ, DB (ਜੇ ਲੋੜ ਹੋਏ) ਲਈ ਇੱਕ
• ਨਾਂ: ਫੋਲਡਰਾਂ ਲਈ ਇੱਕ casing ਸਟਾਈਲ, consistent service names
• ਸਿਕਰੇਟਸ: ਕਦੇ commit ਨਾ ਕਰੋ, ਜੇ leak ਹੋਣ ਤਾਂ rotate ਕਰੋ

ਉਦਾਹਰਨ: ਤੁਸੀਂ web ਨੂੰ ਪੋਰਟ 3000 ਤੇ ਅਤੇ api ਨੂੰ 8080 ਤੇ ਚੁਣਦੇ ਹੋ। ਤੁਹਾਡੀ env ਟੈਮਪਲੇਟ API_URL=http://localhost:8080 ਅਤੇ DATABASE_URL=... ਸ਼ਾਮਲ ਕਰਦੀ ਹੈ। ਜਦੋਂ Claude ਬਾਅਦ ਵਿੱਚ ਸਕ੍ਰਿਪਟ ਅਤੇ ਡੌਕਸ ਜਨਰੇਟ ਕਰੇਗਾ, ਸਭ ਕੁਝ ਥਾਂ ਤੇ ਫਿਟ ਹੋ ਜਾਵੇਗਾ।

Claude Code ਨੂੰ структурਡ ਰੱਖਣ ਲਈ ਕਿਵੇਂ ਪ੍ਰਾਂਪਟ ਕਰੋ

ਰੰਨਯੋਗ scaffold ਮੰਗ ਕੇ ਸ਼ੁਰੂ ਕਰੋ, ਨਾ ਕਿ "ਸਾਰੀ ਐਪ"। ਗੰਦੀ ਆਉਟਪੁੱਟ ਪ੍ਰਾਪਤ ਕਰਨ ਦਾ ਸਭ ਤੋਂ ਤੇਜ਼ ਰਾਸ্তা ਹੈ ਕਿ ਤੁਸੀਂ ਫੀਚਰਾਂ ਦੀ ਮੰਗ ਕਰੋ ਜਦੋਂ ਉਨ੍ਹਾਂ ਨੂੰ ਰੱਖਣ ਲਈ ਕੋਈ ਥਾਂ ਨਹੀਂ ਹੈ।

ਬਣਤਰ ਬਾਰੇ ਸਪਸ਼ਟ ਹੋਵੋ। ਇੱਕ ਫੋਲਡਰ ਲੇਆਉਟ ਦੀ ਮੰਗ ਕਰੋ ਜਿਸ ਵਿਚ ਛੋਟੇ ਟਿੱਪਣੀਆਂ ਹੋਣ ਕਿ ਕੀ ਕਿੱਥੇ ਆਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਕੀ ਨਹੀਂ। ਇਸ ਨਾਲ ਫੈਸਲੇ ਅਗੇ ਆਉਂਦੇ ਹਨ ਨਾ ਕਿ ਹਰ ਵਾਰੀ ਨਵੀਂ ਫਾਇਲਾਂ ਛਿਪਕੀ ਬਣਾਉਂਦੀਆਂ ਜਾਣ।

ਇੱਕ ਸਧਾਰਨ ਤਰੀਕਾ ਜੋ ਇਸਨੂੰ ਅਨੁਸ਼ਾਸਿਤ ਰੱਖਦਾ ਹੈ, ਪ੍ਰਾਂਪਟ ਵਿੱਚ ਨਿਯਮ ਸੈੱਟ ਕਰਨਾ ਹੈ:

• ਸਭ ਤੋਂ ਛੋਟਾ runnable skeleton ਪਹਿਲਾਂ ਜਨਰੇਟ ਕਰੋ (hello page, health endpoint, ਜਾਂ ਇੱਕ ਸਕਰੀਨ)
• ਇੱਕ ਫੋਲਡਰ ਸਟ੍ਰਕਚਰ ਸੁਝਾਓ ਅਤੇ ਹਰ ਫੋਲਡਰ ਦੀ 1-ਵਾਕੀ ਵਿਆਖਿਆ ਦਿਓ
• ਸਕ੍ਰਿਪਟ ਸ਼ਾਮਲ ਕਰੋ ਜੋ ਇੱਕ ਤਾਜ਼ਾ ਮਸ਼ੀਨ 'ਤੇ ਕੰਮ ਕਰਨਗੇ (install, dev, test, build) ਅਤੇ prerequisites ਦਿਓ
• ਬਦਲਾਅ ਇੱਕ PR-ਆਕਾਰ ਚੰਕ ਵਿੱਚ ਰੱਖੋ ਅਤੇ ਸਹੀ-ਸਹੀ ਦੱਸੋ ਕਿਹੜੀਆਂ ਫਾਇਲਾਂ ਬਣਨਗੀਆਂ ਜਾਂ ਸੋਧੀਆਂ ਜਾਣਗੀਆਂ
• scaffolding ਦੇ ਬਾਅਦ ਰੁਕੋ ਅਤੇ ਮੈਨੂੰ ਦੱਸੋ ਕਿ ਕਿਵੇਂ ਚਲਾਉਣਾ ਹੈ

ਇੱਥੇ ਇੱਕ ਪ੍ਰਾਂਪਟ ਹੈ ਜੋ ਤੁਸੀਂ ਦੁਹਰਾ ਕੇ ਐਡਜਸਟ ਕਰ ਸਕਦੇ ਹੋ:

You are working in an empty repo. Create a minimal runnable skeleton.

Constraints:
- Keep it small: no real features yet.
- Propose a clear folder structure and add brief comments in each folder’s README.
- Add scripts for: setup, dev, test, build. They must work on a fresh machine.
- Tell me exactly how to run it, and what output I should see.
- After generating, stop and wait for my “ran it” confirmation.

Output:
1) File tree
2) Key files (only)
3) Run instructions

ਫਿਰ ਲੂਪ ਨੂੰ ਤੰਗ ਰੱਖੋ। ਇੱਕ ਵਾਰੀ ਵਿੱਚ ਪੰਜ ਬਦਲਾਅ ਨਾ ਮੰਗੋ। ਇੱਕ ਛੋਟੀ ਬਦਲਾਅ ਜਨਰੇਟ ਕਰੋ, ਚਲਾਕੇ ਦੇਖੋ, ਸ਼ੁੱਧਗੀ (ਜਾਂ ਸਫਲਤਾ) ਚਿਪਕਾਓ, ਫਿਰ ਇੱਕ ਘੱਟੋ-ਘੱਟ ਫਿਕਸ ਮੰਗੋ। ਇਹ generate-run-adjust ਰਿਦਮ ਪਰੋਜੈਕਟ ਨੂੰ ਭਵਿੱਖਬਾਣੀਯੋਗ ਰੱਖਦੀ ਹੈ ਅਤੇ ਬਣਤਰ ਨੂੰ ਭੁੱਲਣ ਮੁਸ਼ਕਲ ਬਣਾਉਂਦੀ ਹੈ।

ਕਦਮ-ਦਰ-ਕਦਮ: ਖਾਲੀ ਰਿਪੋ ਤੋਂ ਰੰਨਏਬਲ ਸਕੈਫੋਲਡ

ਇੱਕ ਵਾਅਦਾ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ: ਕੋਈ ਵੀ ਰਿਪੋ ਕਲੋਨ ਕਰਕੇ ਇੱਕ ਕਮਾਂਡ ਚਲਾ ਕੇ ਕੁਝ ਚੱਲਦੇ ਹੋਏ ਦੇਖ ਸਕਦਾ ਹੈ। ਇਹ ਤੁਹਾਨੂੰ ਇੱਕ ਸਥਿਰ ਬੇਸ ਦਿੰਦਾ ਹੈ ਬਿਨਾਂ ਇਸਦੇ ਕਿ ਤੁਸੀਂ AI ਤੋਂ ਅਸਲੀ ਫੀਚਰ ਮੰਗੋ।

ਰਿਪੋ ਬਣਾਓ ਅਤੇ ਇੱਕ ਛੋਟੀ README ਲਿਖੋ ਜਦੋਂ ਸਭ ਕੁਝ ਤਾਜ਼ਾ ਹੋਵੇ। ਇਹ ਪ੍ਰਾਇਕਟਿਕ ਹੋਵੇ: prerequisites, ਇੱਕ dev ਕਮਾਂਡ, ਅਤੇ ਤੈਸਟ ਕਿਵੇਂ ਚਲਾਉਣੇ ਹਨ (ਭਾਵੇਂ ਤੈਸਟ ਹੁਣੇ-ਹੁਣੇ ਖਾਲੀ ਹੋਣ)।

ਅਗਲੇ, ਇੱਕ top-level layout ਚੁਣੋ ਜੋ ਤੁਸੀਂ ਚੁਣਿਆ ਆਕਾਰ ਨਾਲ ਮਿਲਦਾ ਹੋਵੇ।

ਜੇ ਤੁਸੀਂ ਕਈ deployable ਟੁਕੜੇ ਬਣਾ ਰਹੇ ਹੋ (ਉਦਾਹਰਨ ਲਈ, frontend + API), ਤਾਂ ਵਰਕਸਪੇਸ ਲੇਆਉਟ ਮਦਦਗਾਰ ਹੋ ਸਕਦਾ ਹੈ:

/
  apps/
  packages/
  scripts/
  docs/
  README.md

ਜੇ ਤੁਸੀਂ ਇੱਕ single app ਦੀ ਨਿਰਮਾਣ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਸਾਦਾ ਰੱਖੋ ਅਤੇ ਜٍਦ ਤੱਕ ਲੋੜ ਨਾ ਹੋਵੇ ਵਾਧੂ ਲੇਅਰ ਨਾ ਬਣਾਓ।

ਹੁਣ ਘੱਟੋ-ਘੱਟ ਗਾਰਡਰੇਲ ਸ਼ਾਮਲ ਕਰੋ ਤਾਂ ਕਿ ਕੋਡ ਇਕਸਾਰ ਰਹੇ। ਇੱਕ formatter ਅਤੇ ਇੱਕ linter ਚੁਣੋ, ਉਨ੍ਹਾਂ ਦੇ ਡੀਫਾਲਟ ਸਵੀਕਾਰ ਕਰੋ, ਅਤੇ ਹਰ ਇਕ ਲਈ ਇਕ ਸਿੰਗਲ ਕਨਫਿਗ ਫਾਇਲ ਸ਼ਾਮਲ ਕਰੋ। ਲਕੜੀ ਦਾ ਮਕਸਦ ਦਿਨ 1 'ਤੇ ਸੁਚਜੇ diffs ਹਨ, ਨਾ ਕਿ ਬਿਲਕੁਲ ਸਹੀ ਨਿਯਮ।

ਡਿਵੈਲਪਰ ਅਨੁਭਵ ਨੂੰ ਇੱਕ ਕਮਾਂਡ ਨਾਲ ਪੇਸ਼ਗੋਈਯੋਗ ਬਣਾਓ। ਇੱਥੇ ਇੱਕ ਸਧਾਰਨ ਆਕਾਰ ਹੈ:

{
  "scripts": {
    "dev": "echo \"start dev server here\"",
    "build": "echo \"build here\"",
    "test": "echo \"tests here\"",
    "lint": "echo \"lint here\""
  }
}

ਕਿਸੇ ਹੋਰ ਚੀਜ਼ ਨੂੰ ਜਨਰੇਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਉਹ dev ਕਮਾਂਡ ਚਲਾਓ, ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਇਹ ਸਾਫ਼ ਨਿਕਲਦਾ ਹੈ (ਜਾਂ ਇੱਕ placeholder ਸਰਵਰ boot ਕਰਦਾ ਹੈ), ਫਿਰ ਪਹਿਲਾ commit ਸਿਰਫ਼ scaffolding ਨਾਲ ਕਰੋ। ਜੇ ਕੋਈ teammate (ਜਾਂ ਭਵਿਖ ਦਾ ਤੁਸੀਂ) ਤਾਜ਼ਾ ਕਲੋਨ ਕਰਕੇ setup reproducible ਕਰ ਸਕਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਪਹਿਲੀ ਸਲਾਈਸ ਬਣਾਉਣ ਲਈ ਤਿਆਰ ਹੋ।

ਐਪ ਵਧਦੇ ਸਮੇਂ ਲਈ ਫੋਲਡਰ ਸਟ੍ਰਕਚਰ

ਇੱਕ ਚੰਗੀ greenfield ਬਣਤਰ ਦੋ ਗੱਲਾਂ ਕਰਦੀ ਹੈ: ਇਹ ਤੁਹਾਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਕੋਡ ਲੱਭਣ ਵਿੱਚ ਮਦਦ ਕਰਦੀ ਹੈ, ਅਤੇ Claude ਨੂੰ ਹਰ ਵਾਰੀ ਨਵੀਆਂ ਰੂਪ-ਰੇਖਾਂ ਬਣਾਉਣ ਦਾ ਘੱਟ ਮੌਕਾ ਦਿੰਦੀ ਹੈ। ਮਕਸਦ ਕਮਾਲ ਨਹੀਂ, ਸਥਿਰਤਾ ਹੈ।

ਜੇ ਤੁਸੀਂ single app ਦੇ ਅੰਦਰ ਕੰਮ ਕਰ ਰਹੇ ਹੋ (ਜਾਂ apps/<name>/ ਫੋਲਡਰ ਅੰਦਰ), ਤਾਂ ਇੱਕ ਸਧਾਰਨ ਅੰਦਰੂਨੀ ਲੇਆਉਟ ਆਮ ਤੌਰ 'ਤੇ ਚੰਗਾ ਕੰਮ ਕਰਦਾ ਹੈ:

• src/ ਐਪ ਕੋਡ (ਫੀਚਰ, ਸਾਂਝੇ ਹਿੱਸੇ, ਐਂਟਰੀ ਪਾਇੰਟ)
• config/ ਗੈਰ-ਸਰਕਰੇਟ ਕਾਨਫਿਗ
• tests/ ਉੱਚ-ਸਤਰ ਦੇ ਟੈਸਟ ਜੋ ਯੂਜ਼ਰ ਵਰਤੋਂ ਵਾਂਗ ਪੜ੍ਹਦੇ ਹਨ
• scripts/ ਸਹਾਇਕ ਸਕ੍ਰਿਪਟ (dev setup, db reset, release tasks)
• docs/ ਛੋਟੀ ਨੋਟਸ ਅਤੇ ਚੈੱਕਲਿਸਟ ਜੋ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਬਰਕਰਾ ਰੱਖਦੇ ਹੋ

src/ ਦੇ ਅੰਦਰ, ਫੀਚਰ ਕੋਡ ਨੂੰ ਸਾਂਝੇ ਕੋਡ ਤੋਂ ਵੱਖਰਾ ਰੱਖੋ ਜੋ ਬਦਲਾਅ ਦੇ ਨਮੂਨੇ 'ਤੇ ਅਧਾਰਤ ਹੋਵੇ। ਫੀਚਰ ਕੋਡ ਅਕਸਰ ਬਦਲਦਾ ਹੈ ਅਤੇ ਇਸ ਨੂੰ ਨੇੜੇ ਰੱਖਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਸਾਂਝਾ ਕੋਡ ਬੋਰਿੰਗ ਅਤੇ ਪੁਨਰਵਰਤੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।

ਇੱਕ ਵਰਤੋਂਯੋਗ ਨਿਯਮ: UI ਸਕ੍ਰੀਨਾਂ, ਹੈਂਡਲਰ, ਅਤੇ ਫੀਚਰ-ਖਾਸ ਲਾਜਿਕ src/features/<featureName>/... ਹੇਠਾਂ ਰੱਖੋ। ਲੋਗਿੰਗ, API clients, design system components, ਅਤੇ ਜੇਨੇਰਿਕ ਯੂਟਿਲਿਟੀਆਂ src/shared/... ਹੇਠਾਂ ਰੱਖੋ। ਜੇ ਕੋਈ ਸਹਾਇਕ ਕੇਵਲ ਇੱਕ ਫੀਚਰ ਲਈ ਮਾਨਸੂਚ ਹੈ, ਤਾਂ ਉਹ ਉਸ ਫੀਚਰ ਵਿੱਚ ਰੱਖੋ ਭਾਵੇਂ ਇਹ ਦੁਬਾਰਾ ਵਰਤਣਯੋਗ ਲੱਗੇ। ਦੂਜੀ ਅਸਲ ਵਰਤੋਂ ਆਉਣ 'ਤੇ ਹਿਲਾਓ।

ਫੋਲਡਰ ਨਾਂ ਦਾ ਮਕਸਦ ਉਦੇਸ਼ ਦਰਸਾਉਣਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਤਕਨੀਕ ਨਹੀਂ। “features” ਅਤੇ “shared” ਤੁਹਾਡੀ ਸਟੈਕ ਬਦਲਣ ਤੇ ਵੀ ਮਾਇਨੇ ਰੱਖਦੇ ਹਨ। “misc” ਜਾਂ “new” ਵਰਗੇ ਨਾਂ ਤੋਂ ਬਚੋ।

docs/ ਨੂੰ ਛੋਟਾ ਰੱਖੋ। ਇੱਕ ਚੰਗਾ ਸ਼ੁਰੂਆਤੀ ਇੱਥੇ docs/checklists.md ਹੋ ਸਕਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਕਈ ਲਾਈਨਾਂ ਹੋਣ: ਕਿਵੇਂ ਚਲਾਉਣਾ, ਕਿਵੇਂ ਟੈਸਟ ਕਰਨਾ, ਨਵਾਂ ਫੀਚਰ ਫੋਲਡਰ ਕਿਵੇਂ ਜੋੜਣਾ, ਅਤੇ “done” ਦਾ ਮਤਲਬ ਕੀ ਹੈ।

ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਪੇਸ਼ਗੋਈਯੋਗ ਬਣਾਉਣ ਵਾਲੇ ਬਿਲਡ ਸਕ੍ਰਿਪਟ

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

ਛੋਟੇ ਕਮਾਂਡ ਸੈੱਟ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਨਿਰਾਸ਼ਪੂਰਨ ਰੱਖੋ। ਜੇ ਕੋਈ ਨਵਾਂ ਆਵੇ (ਜਾਂ ਤੁਸੀਂ ਦੋ ਹਫ਼ਤੇ ਬਾਅਦ ਵਾਪਸ ਆਓ), ਉਹਨਾਂ ਨੂੰ ਕਿਸੇ ਖ਼ਾਸ ਫਲੈਗ ਜਾਂ ਲੁਕਿਆ ਕਦਮ ਦੀ ਲੋੜ ਨਾ ਹੋਵੇ।

ਇੱਥੇ ਇੱਕ ਸਧਾਰਨ ਬੇਸਲਾਈਨ ਹੈ ਜੋ ਕਿਸੇ ਵੀ ਸਟੈਕ ਲਈ ਅਨੁਕੂਲਿਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ:

{
  "scripts": {
    "dev": "node ./scripts/dev.js",
    "build": "node ./scripts/build.js",
    "test": "node ./scripts/test.js",
    "test:quick": "node ./scripts/test.js --quick",
    "test:full": "node ./scripts/test.js --full",
    "format": "node ./scripts/format.js",
    "lint": "node ./scripts/lint.js",
    "smoke": "node ./scripts/smoke.js"
  }
}

dev ਸਕ੍ਰਿਪਟ ਨੂੰ ਖੁਸ਼ਮਿਜ਼ਾਜ਼ ਰਸਤਾ ਬਣਾਓ। ਇਹ ਐਪ ਸ਼ੁਰੂ ਕਰੇ, ਕਿੱਥੇ ਚੱਲ ਰਿਹਾ ਹੈ ਦਿਖਾਏ, ਅਤੇ ਲੌਗਾਂ ਪਠਨਯੋਗ ਰੱਖੇ। ਜੇ ਸਰਵਰ ਸ਼ੁਰੂ ਨਹੀਂ ਹੋ ਸਕਦਾ, ਤਾਂ ਤੇਜ਼ੀ ਨਾਲ ਫੇਲ ਹੋਵੇ ਅਤੇ ਇੱਕ ਸਾਫ਼ ਸੁਨੇਹਾ ਦਿਖਾਏ (missing env var, port already used, database not reachable)।

build ਸਕ੍ਰਿਪਟ ਹਮੇਸ਼ਾਂ ਇੱਕ ਸਾਫ਼ output ਡਾਇਰੈਕਟਰੀ ਬਣਾਉਣਾ ਚਾਹੀਦਾ ਹੈ। ਪੁਰਾਣਾ ਆਊਟਪੁੱਟ ਪਹਿਲਾਂ ਹਟਾਓ, ਫਿਰ ਨਵੇਂ artifacts ਤਿਆਰ ਕਰੋ। ਇਹ ਕੱਲ ਦੇ ਫਾਇਲਾਂ ਕਾਰਨ ਹੋਣ ਵਾਲੀਆਂ ਅਜੀਬ ਬੱਗਾਂ ਨੂੰ ਟਾਲਦਾ ਹੈ।

ਟੈਸਟਾਂ ਲਈ, quick checks ਨੂੰ slow checks ਤੋਂ ਵੱਖ ਕਰੋ। Quick tests ਹਰ ਬਦਲਾਅ 'ਤੇ ਚਲਦੇ ਹਨ (unit tests, type checks). Full tests integration checks ਸ਼ਾਮਲ ਕਰਦੇ ਹਨ ਅਤੇ merge ਤੋਂ ਪਹਿਲਾਂ ਚਲਾਏ ਜਾਣ।

ਸਟਾਈਲ ਇਕ ਕਮਾਂਡ ਨਾਲ ਰੱਖੋ। ਸਧਾਰਨ ਨਿਯਮ: format ਚੀਜ਼ਾਂ ਠੀਕ ਕਰਦਾ ਹੈ, lint ਸ਼ਿਕਾਇਤ ਕਰਦਾ ਹੈ।

ਆਖ਼ਿਰ ਵਿੱਚ, ਇੱਕ smoke check ਜੋ ਮੁਢਲੀ ਚੀਜ਼ਾਂ ਨੂੰ ਵੈਰੀਫਾਈ ਕਰਦਾ ਹੈ ਸ਼ਾਮਲ ਕਰੋ:

• ਜ਼ਰੂਰੀ env vars ਸੈੱਟ ਹਨ (ਅਤੇ ਖਾਲੀ ਨਹੀਂ)
• ਚੁਣੇ ਪੋਰਟ ਖਾਲੀ ਹਨ
• ਐਪ ਇੱਕ ਸਧਾਰਨ অনੁਰੋਧ ਦਾ ਜਵਾਬ ਦੇ ਸਕਦਾ ਹੈ
• ਡੇਟਾਬੇਸ ਕਨੇਕਸ਼ਨ ਕੰਮ ਕਰਦਾ ਹੈ (ਜੇ ਵਰਤਿਆ ਜਾ ਰਿਹਾ ਹੋਵੇ)
• build ਤੋਂ ਬਾਅਦ build ਆਊਟਪੁੱਟ ਮੌਜੂਦ ਹੈ

ਪਹਿਲੀ ਵਰਟੀਕਲ ਸਲਾਈਸ ਬਿਲਡ ਕਰੋ

ਤੁਹਾਡੀ ਪਹਿਲੀ ਵਰਟੀਕਲ ਸਲਾਈਸ end-to-end ਸਾਬਿਤ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ, ਨਾ ਸਿਰਫ UI ਦੀ ਸੁੰਦਰਤਾ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਇੱਕ ਛੋਟਾ ਫੀਚਰ ਜੋ ਸਕਰੀਨ, ਲਾਜਿਕ ਅਤੇ ਕਿਸੇ ਤਰ੍ਹਾਂ ਦੀ ਸਟੋਰੇਜ ਨੂੰ ਛੂਹਦਾ ਹੈ, ਭਾਵੇਂ ਸਟੋਰੇਜ ਅਸਥਾਈ ਹੋਵੇ।

ਕੁਝ ਬੋਰਿੰਗ ਪਰ ਉਪਯੋਗੀ ਚੁਣੋ, ਜਿਵੇਂ “ਨੋਟ ਜੋੜੋ” ਜਾਂ “ਟਾਸਕ ਬਣਾਓ”। ਇਸਨੂੰ ਇੱਕ ਹੀ ਬੈਠਕ ਵਿੱਚ ਮੁਕੰਮਲ ਹੋ ਸਕਣ ਜੋਗਾ ਰੱਖੋ, ਪਰ ਇਹ ਇੰਨਾ ਪੂਰਾ ਹੋਵੇ ਕਿ ਤੁਸੀਂ ਕਲਿੱਕ ਕਰਕੇ ਅਸਲੀ ਸਟੇਟ ਚੇੰਜ ਵੇਖ ਸਕੋ।

ਇੱਕ ਚੰਗੀ ਸਲਾਈਸ ਦੇ ਚਾਰ ਹਿੱਸੇ ਹੁੰਦੇ ਹਨ: ਇੱਕ ਰਾਊਟ ਜਾਂ ਸਕ੍ਰੀਨ, ਇੱਕ ਫਾਰਮ, ਇੱਕ ਸੇਵ ਐਕਸ਼ਨ, ਅਤੇ ਇੱਕ ਪ੍ਰਦਰਸ਼ਨ। ਉਦਾਹਰਨ: “New Task” ਪੇਜ਼ ਜਿਸ ਵਿੱਚ title ਇਨਪੁਟ, Save ਬਟਨ ਜੋ ਇੱਕ ਫੰਕਸ਼ਨ ਨੂੰ ਕਾਲ ਕਰਦਾ ਹੈ, ਅਤੇ ਇੱਕ ਲਿਸਟ ਜੋ ਸੇਵ ਕੀਤੇ ਟਾਸਕ ਦਿਖਾਉਂਦੀ ਹੈ।

ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਵਧਣ ਲਈ ਇੱਕ placeholder store ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਇੱਕ in-memory ਐਰੇ, ਇੱਕ ਲੋਕਲ JSON ਫਾਇਲ, ਜਾਂ ਇੱਕ ਸਧਾਰਨ stub interface ਠੀਕ ਹੈ। ਅਹਮ ਗੱਲ ਇਹ boundary ਬਣਾਉਣਾ ਹੈ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਬਦਲ ਸਕੋ। ਜੇ ਤੁਹਾਡਾ ਕੋਡ ਅੱਜ taskRepository.save(task) ਕਾਲ ਕਰਦਾ ਹੈ, ਤਾਂ ਬਾਅਦ ਵਿੱਚ ਅਸਲੀ ਡੇਟਾਬੇਸ ਨਾਲ ਬਦਲਣਾ ਇੱਕ ਛੋਟੀ ਤਬਦੀਲੀ ਬਣ ਜਾਏਗੀ, ਨਾ ਕਿ ਇੱਕ ਮੁੜ-ਲਿਖਾਈ।

UI ਸਧਾਰਨ ਰੱਖੋ। ਡਿਜ਼ਾਈਨ ਸਿਸਟਮ ਦੀਆਂ ਚਰਚਾਂ, empty states ਅਤੇ ਐਨੀਮੇਸ਼ਨਾਂ ਛੱਡਦੋ।

ਦੋ ਮਿੰਟਾਂ ਵਿੱਚ ਕੀ ਸਵੀਕਾਰਤਾ ਜਾਂਚਾਂ ਕਰੋ:

• ਪੇਜ਼ ਬਿਨਾਂ errors ਖੁਲਦਾ ਹੈ
• ਤੁਸੀਂ ਇਕ ਮੁੱਲ ਟਾਈਪ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ Save ਦਬਾ ਸਕਦੇ ਹੋ
• ਨਵੀਂ ਆਇਟਮ ਤੁਰੰਤ ਦਿੱਖਦੀ ਹੈ
• ਰੀਲੋਡ ਉਮੀਦ ਅਨੁਸਾਰ ਵਿਵਹਾਰ ਦਿਖਾਉਂਦਾ ਹੈ (ਜੇ ਅਸਲੀ ਸਟੋਰੇਜ ਹੈ ਤਾਂ ਪੈਰਸਿਸਟ ਹੋਏ, ਨਾਂ ਹੋਵੇ ਤਾਂ ਰੀਸੈਟ)
• ਖਰਾਬ ਇਨਪੁਟ ਨੂੰ ਹੈਂਡਲ ਕੀਤਾ ਗਿਆ (ਖਾਲੀ title ਸੁਨੇਹਾ ਦਿਖਾਉਂਦਾ ਹੈ ਅਤੇ ਸੇਵ ਨਹੀਂ ਹੁੰਦਾ)

ਇਸਨੂੰ iterate ਕਰਨ ਲਈ ਕਾਫੀ ਸਥਿਰ ਬਣਾਓ

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

ਹਰ ਵਾਰੀ ਤੁਸੀਂ ਇੱਕ ਸਲਾਈਸ ਜੋੜਦੇ ਹੋ, ਇੱਕ ਛੋਟੀ ਸਥਿਰਤਾ ਬਾਰ ਸੈਟ ਕਰੋ:

• ਇੱਕ smoke test ਜੋ ਐਪ boot ਹੋਣ ਅਤੇ ਮੁੱਖ ਰਾਊਟ/ਸਕਰੀਨ render ਹੋਣ ਦਾ ਸਬੂਤ ਦੇਵੇ
• ਇੱਕ smoke test ਜੋ ਸਲਾਈਸ end-to-end ਨੂੰ ਹਿੱਟ ਕਰੇ (ਭਾਵੇਂ ਇਹ ਇੱਕ ਟੈਸਟ ਡੇਟਾਬੇਸ ਵਰਤੇ)
• ਸਾਫ਼ error ਸੁਨੇਹੇ ਜੋ ਆਮ ਯੂਜ਼ਰ ਕਾਰਵਾਈ ਕਰ ਸਕੇ (ਸਟੈਕ ਟਰੇਸ ਨਹੀਂ)
• dev ਲੌਗ ਜੋ ਜੋ ਘਟਿਆ ਉਹ ਸਮਝਾਏ ਬਿਨਾਂ secrets ਛਾਪੇ
• ਘੱਟੋ-ਘੱਟ ਡਿਪੈਂਡੇੰਸੀਜ਼, version pinned, upgrades ਇਰਾਦੇ ਨਾਲ

ਕਾਂਕਰੀਟ ਉਦਾਹਰਨ: ਤੁਹਾਡੀ ਪਹਿਲੀ ਸਲਾਈਸ ਇੱਕ "Project" ਬਣਾਉਣ ਦਿੰਦੀ ਹੈ ਅਤੇ ਇਸਨੂੰ ਲਿਸਟ ਵਿੱਚ ਵੇਖਾਉਂਦੀ ਹੈ। ਇੱਕ ਟੈਸਟ ਜੋ ਸਰਵਰ start ਕਰਦਾ ਹੈ, create endpoint ਨੂੰ ਕਾਲ ਕਰਦਾ ਹੈ, ਫਿਰ ਲਿਸਟ ਫੈਚ ਕਰਦਾ ਹੈ ਅਤੇ ਚੈੱਕ ਕਰਦਾ ਹੈ ਕਿ ਨਵਾਂ ਆਈਟਮ ਪੌਪ ਹੋ ਗਿਆ—ਇਹ ਫੇਲ ਹੋਵੇ ਤਾਂ ਤੇਜ਼ੀ ਨਾਲ ਇੱਕ ਮਦਦਗਾਰ ਸੁਨੇਹਾ ਦੇਵੇ, ਜਿਵੇਂ "Create Project endpoint returned 500"—ਨਾ ਕਿ ਬਹੁਤ ਸਾਰਾ ਆਊਟਪੁੱਟ।

ਐਰਰ ਹੈਂਡਲਿੰਗ ਲਈ, ਇੱਕ ਛੋਟੇ ਅਤੇ ਇੱਕਸਾਰ ਜਵਾਬਾਂ ਦੇ ਸੈੱਟ 'ਤੇ ਟਿਕੋ। ਵੈਲਿਡੇਸ਼ਨ ਐਰਰ ਇੱਕ ਛੋਟਾ ਸੁਨੇਹਾ ਦੇ ਤਾਂ ("Name is required") ਅਤੇ ਇੱਕ field name। ਅਣ-ਉਮੀਦ ਕੀਤੇ ਐਰਰ "ਕੁਝ ਗਲਤ ਹੋ ਗਿਆ। ਫੇਰ ਕੋਸ਼ਿਸ਼ ਕਰੋ." ਦੇਣ। ਵੇਰਵੇ logs ਵਿੱਚ ਰੱਖੋ।

ਲੋਗਿੰਗ ਸਭ ਤੋਂ ਫਾਇਦੇਮੰਦ ਹੁੰਦੀ ਹੈ ਜਦ ਇਹ ਉੱਤਰ ਦਿੰਦੀ ਹੈ: ਕਿਹੜੀ ਬੇਨਤੀ, ਕਿਹੜਾ ਯੂਜ਼ਰ (ਜਾਂ ਅਜਾਣ), ਕੀ ਫੇਲ ਹੋਇਆ, ਅਤੇ ਕਿੱਥੇ। dev ਵਿੱਚ request id ਅਤੇ timing ਸ਼ਾਮਲ ਕਰੋ, ਪਰ ਡੀਫਾਲਟ ਰੂਪ ਵਿੱਚ ਟੋਕਨ, ਪਾਸਵਰਡ, API keys ਜਾਂ ਪੂਰਾ payload ਨੂੰ dump ਕਰਨ ਤੋਂ ਬਚੋ।

ਇੱਕ ਛੋਟਾ health check ਜੋੜੋ। ਵੈੱਬ 'ਤੇ ਇਹ ਇੱਕ /health endpoint ਹੋ ਸਕਦਾ ਹੈ ਜੋ ok ਰਿਟਰਨ ਕਰੇ। ਮੋਬਾਈਲ 'ਤੇ ਇਹ "Connected" ਸਥਿਤੀ ਹੋ ਸਕਦੀ ਹੈ ਜੋ backend ਨਾਲ ਨਾਂ ਜੁੜੇ ਤਾਂ "Offline" ਹੋ ਜਾਵੇ। ਇਹ debug ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਤੇਜ਼ signal ਹੈ।

AI ਵਰਤ ਕੇ greenfield ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚ ਆਮ ਜਾਲ

ਸਭ ਤੋਂ ਤੇਜ਼ੀ ਨਾਲ greenfield ਸ਼ੁਰੂਆਤ ਨੁਕਸਾਨ ਵਿੱਚ ਪਾਉਣ ਦਾ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ ਮਾਡਲ ਤੋਂ ਪੂਰੀ ਐਪ ਮੰਗੋ ਅਤੇ ਫਿਰ ਥੋੜ੍ਹੇ ਸਮੇਂ ਬਾਅਦ ਹੀ ਇਸ ਨੂੰ ਚਲਾਉ। ਵੱਡੀਆਂ ਜਨਰੇਸ਼ਨ ਛੋਟੀ ਗਲਤੀਆਂ ਨੂੰ ਛੁਪਾਉਂਦੀਆਂ ਹਨ: ਗੁੰਮ ਡਿਪੈਂਡੇੰਸੀਜ਼, ਗਲਤ import paths, ਸਕ੍ਰਿਪਟ ਜੋ ਐਸੇ ਟੂਲ assume ਕਰਦੇ ਹਨ ਜੋ ਤੁਹਾਡੇ ਕੋਲ ਨਹੀਂ ਹਨ। ਹਰ ਆਉਟਪੁੱਟ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਮਾਨੋ ਕਿ ਤੁਹਾਨੂੰ ਕੁਝ ਮਿੰਟਾਂ ਵਿੱਚ ਚਲਾ ਕੇ ਵੇਖਣਾ ਚਾਹੀਦਾ ਹੈ।

ਇੱਕ ਹੋਰ ਜਾਲ ਇਹ ਹੈ ਕਿ ਬਿਨਾਂ ਕਿਸੇ ਫੀਚਰ ਦੇ "ਸ perfeito" ਆਰਕੀਟੇਕਚਰ ਡਿਜ਼ਾਈਨ ਕਰਨਾ। ਫੋਲਡਰ ਨਾਂ 'ਤੇ ਚਰਚਾ ਉਤਪਾਦਕ ਲੱਗ ਸਕਦੀ ਹੈ, ਪਰ ਜਦ ਤੱਕ ਕੋਈ ਸਲਾਈਸ ਨਹੀਂ ਹੈ ਤੁਸੀਂ ਨਹੀਂ ਜਾਣ ਸਕਦੇ ਕਿ ਕੀ ਅਸਲ ਵਿੱਚ ਅਸਹਜ ਹੈ। ਇੱਕ ਸਧਾਰਨ ਬਣਤਰ ਜੋ ਇੱਕ ਚੱਲਦੇ ਰਸਤੇ ਨੂੰ ਸਹਾਰਦਾ ਹੈ, ਇੱਕ ਚਤੁਰ ਬਣਤਰ ਨਾ ਜਾਣੇ ਕਿੰਨੀ ਵਧੀਆ ਹੈ।

Command drift ਵੀ ਆਮ ਹੈ। AI ਨਵਾਂ ਤਰੀਕਾ ਸ਼ੁਰੂ ਕਰਨ ਦਾ ਜੋੜ ਦਿੰਦਾ ਹੈ, ਤੁਸੀਂ ਹੋਰ ਇੱਕ ਸ਼ਾਮਲ ਕਰਦੇ ਹੋ, ਅਤੇ ਜਲਦੀ ਹੀ ਕਿਸੇ ਨੂੰ ਨਹੀਂ ਪਤਾ ਹੁੰਦਾ ਕਿ "ਕਿਹੜਾ" ਕਮਾਂਡ ਹੈ। ਜੇ ਕੋਈ teammate ਰਿਪੋ ਕਲੋਨ ਕਰਕੇ ਪੁڇੇ "ਇਸ ਨੂੰ ਚਲਾਉਣਾ ਕਿਵੇਂ ਹੈ?", ਤਾਂ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਲਿਆਣ ਰਹੇ ਹੋ।

ਜੇੜੀਆਂ ਗਲਤੀਆਂ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਦੁਬਾਰਤਾ ਲਿਆਉਂਦੀਆਂ ਹਨ:

• ਇੱਕ runnable ਰਸਤੇ ਪਹਿਲਾਂ ਬਣਾਉਣ ਦੀ ਥਾਂ ਇੱਕ ਵਾਰੀ ਵਿੱਚ ਬਹੁਤ ਸਾਰੀਆਂ ਸੇਵਾਵਾਂ, ਸਕਰੀਨਾਂ, ਅਤੇ configs ਜਨਰੇਟ ਕਰਨਾ
• ਪਹਿਲੀ ਫੀਚਰ end-to-end ਕੰਮ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ auth, payments, complex styling, ਅਤੇ ਪੂਰਾ ਡੇਟਾ ਮਾਡਲ ਖਿੱਚ ਲੈਣਾ
• setup ਨਿਰਦੇਸ਼ਾਂ ਨੂੰ chat ਵਿੱਚ ਛੱਡ ਦੇਣਾ ਬਜਾਏ ਸਕ੍ਰਿਪਟਾਂ (ਜਾਂ ਇੱਕ README) ਵਿੱਚ ਰੱਖਣਾ
• ਇੱਕ ਸਾਫ਼ env ਟੈਮਪਲੇਟ ਭੁੱਲ ਜਾਣਾ, ਤਾਂ ਕਿ ਅਗਲੇ ਮਸ਼ੀਨ ਨਾਲ ਸ਼ੁਰੂ ਕਰਨਾ ਅਨੁਮਾਨੀ ਬਣ ਜਾਵੇ

ਸਧਾਰਨ ਉਦਾਹਰਨ: ਤੁਸੀਂ "complete" ਐਪ ਜਨਰੇਟ ਕਰਦੇ ਹੋ ਜਿਸ ਵਿੱਚ login, theming, ਅਤੇ billing ਹੈ, ਪਰ ਪਹਿਲੀ ਰਨ fail ਹੋ ਜਾਂਦੀ ਹੈ ਕਿਉਂਕਿ ਇੱਕ secret key ਗੁੰਮ ਹੈ ਅਤੇ ਕੋਈ .env.example ਨਹੀਂ ਹੈ। ਫਿਰ ਤੁਸੀਂ ਇਕ ਘੰਟਾ setup ਠੀਕ ਕਰਨ ਵਿੱਚ ਗੁਜਾਰਦੇ ਹੋ ਬਜਾਏ ਇਸ ਦੇ ਕਿ ਤੁਸੀਂ ਸਿੱਖ ਸਕੋ ਕਿ ਫੀਚਰ ਉਪਯੋਗੀ ਹੈ ਜਾਂ ਨਹੀਂ।

ਇਮਾਨਦਾਰ ਰਹੋ: ਇੱਕ runnable ਕਮਾਂਡ, ਇੱਕ ਛੋਟੀ ਫੀਚਰ, ਇੱਕ env ਟੈਮਪਲੇਟ, ਫਿਰ ਵਧਾਓ।

iterate ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਤੁਰੰਤ ਚੈੱਕਲਿਸਟ

"ਹੋਰ ਇੱਕ ਫੀਚਰ" ਜੋੜਣ ਤੋਂ ਪਹਿਲਾਂ ਸੁਨਿਸ਼ਚਿਤ ਕਰੋ ਕਿ ਪ੍ਰੋਜੈਕਟ ਅਗਲੇ ਦਿਨ (ਜਾਂ ਕਿਸੇ ਹੋਰ ਵਿਅਕਤੀ ਦੁਆਰਾ) ਆਸਾਨੀ ਨਾਲ ਉਠਾਇਆ ਜਾ ਸਕੇ। ਗਤੀ ਹੀ ਲਕਸ਼ ਨਹੀਂ। ਪੇਸ਼ਗੋਈਯੋਗਤਾ ਹੈ।

• ਇੱਕ-ਕਮਾਂਡ ਰਨ: ਨਵਾਂ ਡਿਵੈਲਪਰ env ਟੈਮਪਲੇਟ ਕਾਪੀ ਕਰਕੇ, ਕੁਝ ਲੋੜੀਂਦੇ ਮੁੱਲ ਸੈੱਟ ਕਰ ਕੇ, ਇੱਕ ਕਮਾਂਡ ਨਾਲ ਐਪ ਚਲਾ ਸਕੇ। ਜੇ ਇਹ ਹੋਰ ਕਦਮ ਲੈਣੇ (DB setup, migrations, seed data) ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਉਹਨਾਂ ਨੂੰ ਸਕ੍ਰਿਪਟ ਵਿੱਚ ਦਰਜ ਕਰੋ।
• ਸਕ੍ਰਿਪਟ ਮੁਢਲਾ ਕੰਭਰ: dev, test, build, ਅਤੇ ਇੱਕ ਤੇਜ਼ smoke ਚੈੱਕ ਲਈ ਸਪਸ਼ਟ ਕਮਾਂਡ।
• ਸਪਸ਼ਟ ਬਣਤਰ: ਲੇਆਉਟ ਇੱਕ ਕਹਾਣੀ ਦੱਸਦਾ ਹੈ (ਐਪ ਕੋਡ, config, ਸਕ੍ਰਿਪਟ, ਟੈਸਟ) ਬਿਨਾਂ ਸਾਰੇ ਕੋਡਬੇਸ ਨੂੰ ਪੜ੍ਹਨ ਦੇ।
• ਵਰਟੀਕਲ ਸਲਾਈਸ ਡੈਮੋ ਪਾਥ: ਤੁਸੀਂ ਡੈਮੋ ਇੱਕ ਵਾਕ ਵਿੱਚ ਵਰਣਨ ਕਰ ਸਕਦੇ ਹੋ, ਜਿਵੇਂ "ਇਕ ਆਈਟਮ ਬਣਾਓ, ਲਿਸਟ ਵਿੱਚ ਵੇਖੋ, ਰੀਫ੍ਰੇਸ਼ ਕਰੋ, ਇਹ ਅਜੇ ਵੀ ਉਥੇ ਹੈ।"
• ਰੋਲਬੈਕ ਪੁਆਇੰਟ: ਵੱਡੇ ਬਦਲਾਅ ਤੋਂ ਪਹਿਲਾਂ, ਤੁਹਾਡੇ ਕੋਲ ਵਾਪਸ ਜਾਣ ਲਈ ਸੁਰੱਖਿਅਤ ਬਿੰਦੂ ਹੋਵੇ (ਇੱਕ ਕਲੀਨ commit, ਇੱਕ tag, ਜਾਂ ਇੱਕ snapshot/rollback ਮਕੈਨਿਜ਼ਮ)।

ਜੇ ਕੋਈ ਆਈਟਮ fail ਹੋਵੇ, ਤਾਂ ਹੁਣ ਹੀ ਠੀਕ ਕਰੋ। ਸਕ੍ਰਿਪਟਾਂ ਅਤੇ ਨਾਮਕਰਨ ਨੂੰ ਕਸਨਾ ਛੋਟਾ ਖਰਚ ਹੈ ਜਦ ਰਿਪੋ ਛੋਟਾ ਹੋਵੇ।

ਅਗਲੇ ਕਦਮ: ਵਰਕਫਲੋ ਨੂੰ ਦੁਹਰਾਊ ਆਦਤ ਬਣਾਓ

ਇੱਕ greenfield ਸ਼ੁਰੂਆਤ ਤਦ ਹੀ ਲਾਭਕਾਰੀ ਹੁੰਦੀ ਹੈ ਜਦ ਤੁਸੀਂ ਇਸਨੂੰ ਦੁਹਰਾਉ। ਆਪਣੀ ਪਹਿਲੀ ਵਰਟੀਕਲ ਸਲਾਈਸ end-to-end ਚੱਲਣ ਤੋਂ ਬਾਅਦ, ਚੰਗੀਆਂ ਚੀਜ਼ਾਂ ਨੂੰ ਇੱਕ ਛੋਟੀ ਟੈਂਪਲੇਟ ਵਿੱਚ ਫ੍ਰੀਜ਼ ਕਰੋ: ਉਹੀ ਫੋਲਡਰ ਪੈਟਰਨ, ਉਹੀ ਸਕ੍ਰਿਪਟ ਨਾਂ, ਅਤੇ UI, API, ਅਤੇ ਡੇਟਾ ਨੂੰ ਜੋੜਨ ਦਾ ਉਹੀ ਤਰੀਕਾ।

ਆਪਣੀ ਪਹਿਲੀ ਸਲਾਈਸ ਨੂੰ ਇੱਕ ਰੈਫਰੈਂਸ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਵਜੋਂ ਲਓ। ਜਦ ਤੁਸੀਂ ਸਲਾਈਸ #2 ਸ਼ੁਰੂ ਕਰੋ, ਆਕਾਰ ਕਾਪੀ ਕਰੋ, ਕੋਡ ਨਹੀਂ। ਜੇ ਸਲਾਈਸ #1 ਵਿੱਚ ਇੱਕ ਰਾਊਟ, ਇੱਕ ਹੈਂਡਲਰ, ਇੱਕ ਡੇਟਾ ਐਕਸੈਸ ਲੇਅਰ, ਅਤੇ ਇੱਕ ਬੁਨਿਆਦੀ ਟੈਸਟ ਹੈ, ਤਾਂ ਸਲਾਈਸ #2 ਨੂੰ ਉਹੀ ਰਸਤਾ ਫੋਲੋ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।

ਯੋਜਨਾ ਬਣਾਉਣਾ ਹਲਕਾ ਰੱਖੋ। 2-3 ਸਲਾਈਸ ਲਈ ਇੱਕ ਪੇਜ ਦੀ ਨੋਟ ਕਾਫੀ ਹੈ: ਹਰ ਸਲਾਈਸ ਲਈ ਲਕ�