ఈ AI Software Factory రిపాజిటరీ ఉత్పత్తి లక్ష్యం, పని నుంచి Archon తయారుచేసే పుల్ రిక్వెస్ట్ వరకు మార్గాన్ని వివరిస్తుంది. ఇన్‌స్టాలేషన్, వర్క్‌ఫ్లో తనిఖీలు ఆరంభం మాత్రమే. నిర్వహణకర్త మొదటి గంట మార్గదర్శిని లో నిజమైన ప్రారంభం నుంచి ముగింపు వరకు ధృవీకరణ ఇంకా చేయాల్సి ఉందని చెప్పారు. ఈ మార్గదర్శిని ఫ్యాక్టరీ కమిట్ 9e2d85298b45497031009597a6ae0811b66fe6d6 , దానిలో నిర్దేశించిన Archon రివిజన్ fad09169ea1b43512bc7ee88470d47f960a3e0f8 ను అనుసరిస్తుంది. ఇది పత్రాలు, కోడ్ చదివిన వివరణ; BIG CHANGE ఇన్‌స్టాల్ చేసి నడిపిన నివేదిక కాదు.

యాప్ రిపాజిటరీ లేదా PRD, GitHub అనుమతులు, మోడల్ ప్రదాత ఖాతాపై నియంత్రణ ఉన్న బృందానికి ఈ విధానం వర్తిస్తుంది. నిర్వహణకర్త సొంత రిపాజిటరీలో ఫ్యాక్టరీని క్లోన్ చేసి ఇన్‌స్టాల్ చేసే విధానాన్ని స్పష్టంగా వివరిస్తారు. నిర్దిష్ట ఫ్యాక్టరీ ఫైల్ నిర్మాణంలో లైసెన్స్ లేదా నోటీసు ఫైల్ లేదు; ఈ మార్గదర్శిని విస్తృత పునర్వినియోగ లేదా పునఃపంపిణీ హక్కులను స్థాపించదు. Archon MIT లైసెన్స్ విడి Archon మూలానికి వర్తిస్తుంది. ప్రదాత రహస్యాలను పని వివరణ, ప్రాంప్ట్‌లు, లాగ్‌లు, సమీక్ష రికార్డుల్లో పెట్టవద్దు.

పెద్ద మార్పు

  • ఏం మారింది: ఈ అమలు నిర్దిష్ట Archon వర్క్‌ఫ్లో ప్యాక్‌తో ఉత్పత్తి పరిధి, పని ప్రణాళిక, ప్రోగ్రామింగ్, స్వతంత్ర సమీక్ష, అమలు తనిఖీలను కలుపుతుంది. ఫ్యాక్టరీ ప్రాజెక్టు ఇన్‌పుట్, లాంచర్ ఇస్తుంది; ఉమ్మడి ప్యాక్‌లో AI దశలు ఉంటాయి.
  • ఎందుకు ముఖ్యం: మర్జ్ నిర్ణయానికి ముందు బృందం ప్రతిపాదనను పని నుంచి నిర్దిష్ట తేడా, CI ఫలితం, నడుస్తున్న అభ్యర్థి వరకు అనుసరించవచ్చు. ఇన్‌స్టాలేషన్ తనిఖీలతోనే ఈ ఆధారాల గొలుసు పూర్తికాదు; నిర్వహణకర్త నిజమైన సమన్వయ ధృవీకరణ ఇంకా అవసరమని చెబుతున్నారు.
  • ఏం గమనించాలి: ఉపయోగకరమైన మొదటి ఆధారం నిజమైన పని: దాని సరఫరా రివిజన్ అర్థవంతమైన ప్రక్రియలు, స్వతంత్ర ప్రత్యేక టెస్టులు దాటాలి; ఖర్చు, సమీక్ష రికార్డు బృందానికి కనిపించాలి. తరువాత కూడా షెడ్యూల్, డిప్లాయ్‌మెంట్ విడి నిర్ణయాలే.

1. రిపాజిటరీ, అనుమతులు, నిర్దిష్ట మూలాన్ని తనిఖీ చేయండి

నిర్వహణకర్త ఏర్పాటు సూచనలు ప్రకారం Git, Python 3.10 లేదా కొత్తది, ధృవీకరించిన gh , దానికి workflow పరిధి ఉండాలి, GitHub రిమోట్, కోడింగ్ ఏజెంట్, Bun, uv అవసరం. Git వర్క్‌ఫ్లో ఫైళ్లను కూడా పుష్ చేయగలగాలి ( gh auth setup-git ). ఏజెంట్‌ను నడిపే ముందు ప్రస్తుత టెస్ట్, ప్రారంభ, CI కమాండ్‌లు, బ్రాంచ్ రక్షణ, GitHub ప్రవేశం, ప్రదాత ధృవీకరణ, మోడల్ బిల్లింగ్ తనిఖీ చేయండి. అవసరమైన రిపాజిటరీ, వర్క్‌ఫ్లో అధికారాలే ఇవ్వండి.

యాప్ రిపాజిటరీ బయట ఫ్యాక్టరీని క్లోన్ చేసి పేర్కొన్న కమిట్‌కు మారండి. పత్రంలోని ఇన్‌స్టాలేషన్ కమాండ్‌ను యాప్ మూల డైరెక్టరీ నుంచి నడపాలి:

Terminal
git clone https://github.com/coleam00/ai-software-factory ~/ai-software-factory
git -C ~/ai-software-factory checkout 9e2d85298b45497031009597a6ae0811b66fe6d6
python ~/ai-software-factory/bin/factory.py init

అవసరమైతే python3 వాడండి. ఇన్‌స్టాలర్ ఫ్యాక్టరీ, ప్రాజెక్టు నమూనాలను కాపీ చేసి pack.json లో పేర్కొన్న Archon మూలాన్ని ఇన్‌స్టాల్ చేస్తుంది. ఈ కమిట్‌లో README, ప్యాక్ రెండూ fad09169ea1b43512bc7ee88470d47f960a3e0f8 ను సూచిస్తాయి. ఇన్‌స్టాలర్ ప్రదాతను ధృవీకరించదు, మోడల్ స్థాయిలను ఎంచుకోదు, షెడ్యూల్ ప్రారంభించదు. రిపాజిటరీలో మార్పులు అంగీకరించే ముందు వాస్తవ ఫైల్ మార్పులు చూడండి.

ఇన్‌స్టాల్ చేసిన Archon సూచనలతో ఎంచుకున్న ప్రదాత, మద్దతున్న మోడల్ గుర్తింపులను అమర్చండి. ప్రాజెక్టు నిజమైన స్థిర విశ్లేషణ, యూనిట్ టెస్ట్ కమాండ్‌లను harness/harness.config.json లో పెట్టండి. GitHub బ్రాంచ్ రక్షణ వివరాలు చెప్పలేకపోతే మర్జ్‌కు అవసరమైన CI పనులను required_checks లో పేర్కొనండి. లక్ష్యం, ధృవీకరణ చట్రం, ఫ్యాక్టరీ విధానం మార్చడానికి మనిషి అవసరమయ్యేలా protected_paths చూడండి. నమూనాలో సాధారణ తనిఖీ కమాండ్‌లు, required_checks ఖాళీగా ఉంటాయి; కాపీ చేయడం మాత్రమే ఉపయోగకరమైన అంగీకార అడ్డుకట్టను ఏర్పరచదు.

2. ఉన్న ఉత్పత్తికి లక్ష్యం, తనిఖీలు రాయండి

ఫైల్ MISSION.md లో ఉత్పత్తి ఉద్దేశం, కఠిన పరిమితులు, సాధ్యమైనా పరిధి బయట ఉండే అభ్యర్థనలు రాయండి. harness/END-TO-END.md లో ప్రస్తుత యాప్ నిజంగా పూర్తి చేసే రెండు నుంచి ఐదు వినియోగదారు ప్రక్రియలను, వారికి కనిపించే విలువతో వివరించండి. ఇంకా నిర్మించని సౌకర్యం అవసరమైన ప్రక్రియ మొదటి సరఫరాను అడ్డుకుంటుంది. .factory/holdout/HOLDOUT.md లో ప్రవర్తనల కలయికలు లేదా సరిహద్దు పరిస్థితులు పరీక్షించే ప్రత్యేక కేసులు రాయండి. అదే చెకౌట్‌కు ప్రవేశం ఉన్న డెవలపర్ నుంచి డైరెక్టరీ పేరు కేసులను దాచదు; నిజంగా గోప్యమైన కేసులు బయట ఉంచి ధృవీకరణకు మాత్రమే ఇవ్వండి.

PRD మాత్రమే ఉన్న రిపాజిటరీకి README పత్రం నుంచి లక్ష్యం, ఉద్దేశించిన ప్రక్రియలు, తనిఖీ కమాండ్‌లు తీసుకోమంటుంది. మొదటి ప్రతిపాదిత పని ఉత్పత్తి నడిచేలా చేసి ప్రారంభ కమాండ్, ఆరోగ్య స్థితి, బిల్డ్ గుర్తింపు మార్గాలు, టెస్టులు, CI పేర్కొనాలి. పనులు ప్రచురించడానికి అనుమతించే ముందు ప్రతిపాదన సమీక్షించండి.

ప్రక్రియలను Archon అమలు వర్క్‌ఫ్లోలు ఆశించే దృశ్య ఇన్‌పుట్‌లుగా మార్చండి. ఇన్‌స్టాల్ చేసిన factory/RUNTIME_HOST.md ను అనుసరించి అందించిన కమిట్ నుంచి యాప్ ప్రతిరూపం, కొత్త స్థితి, ఆరోగ్య, బిల్డ్ గుర్తింపు తనిఖీలు, అనుమతించిన Python లేదా Node ప్రారంభ కమాండ్‌లు సిద్ధం చేయండి. పత్రంలోని హోస్ట్ దూరపు డేటాబేసులు, కంటైనర్లు, క్లౌడ్ వనరులను తన నిర్వహణలోని అమలు వనరులుగా మద్దతివ్వదు. అవి ఉపయోగించే యాప్‌కు విడిగా సమర్థించిన ధృవీకరణ ఏర్పాటు అవసరం; స్థానిక హోస్ట్ పరీక్ష విజయం వాటి వేరుపాటును నిరూపించదు.

మూల్యాంకనంపై ఆధారపడే ముందు నిజమైన వినియోగదారు విలువను పరీక్షించే విజయవంతమైన ప్రాథమిక స్థాయి ఏర్పరచండి, సంబంధిత ఉద్దేశపూర్వక లోపం విఫలమవుతుందని చూపండి, తప్పు అభ్యర్థి గుర్తింపు అనిర్ణీత తీర్పు ఇస్తుందో చూడండి. హోస్ట్ మార్గదర్శినిలో పరీక్ష సమూహ ఇన్‌పుట్‌లు, ఖచ్చితమైన ఆశించిన ఫీల్డ్‌లు ఉన్నాయి; వాటిలో expectations_passed: true , baseline_verified: true ఉన్నాయి. అసలు వచ్చిన స్పందన, అభ్యర్థి గుర్తింపును ఆధారంగా ఉంచండి. పేజీ లోడ్ అవడమే చూడటం లేదా పరీక్ష చివరి స్థితిని నేరుగా సిద్ధం చేయడం సరిపోదు.

3. ఇన్‌స్టాలేషన్ తనిఖీ చేసి ఒక పని ఎంచుకోండి

యాప్ మూల డైరెక్టరీ నుంచి నడపండి:

Terminal
python factory/consumer.py doctor
python factory/consumer.py list

doctor నిర్దిష్ట మూలం, కమాండ్ సామర్థ్యాలు, అందుబాటులో ఉన్న వర్క్‌ఫ్లోలను తనిఖీ చేస్తుంది. list గుర్తించిన వర్క్‌ఫ్లోలను చూపిస్తుంది. ప్రదాత పని పూర్తి చేస్తాడని, CI విజయవంతమవుతుందని, యాప్ నడుస్తుందని ఇవి నిరూపించవు. సరఫరాకు ముందు తెలిపిన లోపాలు పరిష్కరించండి; షెడ్యూల్ ఆఫ్‌లో ఉంచండి.

ఉన్న కోడ్‌కు స్పష్టమైన ఫలితం, అంగీకార తనిఖీలు గల చిన్న పని రాయండి. వర్గీకరణ, సరఫరా, సమీక్ష నుంచి పుల్ రిక్వెస్ట్ వరకు README ఈ కమాండ్‌ను వివరిస్తుంది:

Terminal
python factory/consumer.py run archon-ship --input target=https://github.com/OWNER/REPO/issues/1 --input discovery_publication=preview --detach --json

పని URL స్థానంలో మీ నియంత్రణలోని పని పెట్టండి. స్పష్టమైన discovery_publication=preview సమీక్షలోని సంబంధిత అంశాలను పనులుగా ప్రచురించదు; నిర్దిష్ట archon-ship అప్రమేయంగా auto వాడుతుంది. అమలు దృశ్యం, ప్రత్యేకంగా నిలిపిన టెస్ట్ ఇన్‌పుట్‌లు సిద్ధమైన తరువాతే archon-lifecycle వాడండి. పనిని target , మార్గాలను scenario , holdout గా పంపండి; merge_mode=approve , discovery_publication=preview కూడా ఇవ్వండి. ప్రాజెక్టు ఆమోదించిన merge_method అవసరం: merge , squash లేదా rebase . ఉదాహరణకు రిపాజిటరీ అనుమతిస్తేనే merge_method=squash వాడండి. ఈ ప్రవాహంలో అమలు, ప్రత్యేక కేసుల ధృవీకరణ, మరమ్మతు, మర్జ్ తనిఖీ ఉంటాయి. ఆమోద విధానం మర్జ్ ముందు మానవ నిర్ణయాన్ని ఉంచుతుంది; వర్క్‌ఫ్లో సిద్ధం గుర్తు ఆ నిర్ణయం కాదు. ఫ్యాక్టరీ హోస్ట్‌లో పత్రబద్ధమైన --runtime-host ముందుభాగంలో మాత్రమే నడుస్తుంది; --detach , --resume తో కలపలేరు.

PRD కోసం పత్రబద్ధమైన బ్యాక్‌లాగ్ కమాండ్:

Terminal
python factory/consumer.py run archon-backlog --input 'prd=docs/PRD.md' --input publication=approve

కొటేషన్లలోని docs/PRD.md ను యాప్ చెకౌట్‌కు సాపేక్షంగా అసలు PRD మార్గంతో మార్చండి. ప్రచురణకు ముందు సూచించిన పనుల క్రమాన్ని సమీక్షించండి. మొదటి పనిలో ప్రకటించిన యాప్ ప్రారంభ విధానం, గుర్తింపు ఒప్పందం ప్రకారం అమలు హోస్ట్ కలపండి; సిద్ధం చేసిన ప్రక్రియలు, ప్రత్యేక టెస్టులతో పనిని archon-lifecycle ద్వారా నడపండి. మొదటి పనినీ తరువాతి పనులంత జాగ్రత్తగా చూడాలి.

4. ఆమోదానికి ముందు తేడాలు, నడిచే ఫలితాన్ని అంచనా వేయండి

వచ్చిన run ID ఉంచండి. నియంత్రణ ప్రోగ్రామ్ పురోగతి, ఆధారాల కోసం get <run-id> --json --events , status --all --json ఇస్తుంది. పని, ప్రణాళికను MISSION.md తో పోల్చండి; అసలు PR తేడాలు, తాజా రివిజన్ స్వతంత్ర సమీక్ష చదవండి; అవసరమైన CI ఫలితాలు, రక్షిత మార్గాల నివేదిక చూడండి. ఇచ్చిన రివిజన్‌పై ఉత్పత్తి ప్రక్రియలు నడిపి అభ్యర్థి గుర్తింపుతో సహా అసలు అమలు, ప్రత్యేక టెస్ట్ ఫలితాలు పరిశీలించండి. కనిపించిన వినియోగదారు ఫలితాన్ని అంగీకార ప్రమాణాలతో పోల్చండి. లోపమున్న PR మరమ్మతుకు తిరిగి పంపాలి; మర్జ్ క్యూ నిలిపిన సరఫరాకు README archon-deliver --adopt <run id> ను వివరిస్తుంది.

తనిఖీలు విజయవంతమైన తర్వాత రిపాజిటరీ అధికారం ఉన్న మనిషి మాత్రమే మర్జ్ ఆమోదించాలి. డిప్లాయ్‌మెంట్‌కు ప్రాజెక్టు ప్రత్యేక అమరిక, ఆరోగ్య, గుర్తింపు కమాండ్‌లు, తరువాత రివిజన్ మళ్లీ చదివి ధృవీకరించడం అవసరం. మర్జ్ చేసిన PR ఒక్కటే డిప్లాయ్‌మెంట్ ఆధారం కాదు. మొదటి పని అంతా షెడ్యూల్ ఆఫ్‌లో ఉంచి పునరావృత అమలు కావాలా విడిగా నిర్ణయించండి.

నిర్వహణకర్త ఖర్చు సూచనలు ఒక్క అమలుకు స్థిర ధర ఇవ్వవు. మొదటి రోజు నుంచే టోకెన్లు కొలవాలని, లూప్ ప్రారంభించే ముందు చిన్న పనిలో మోడల్ కాల్స్ గమనించాలని సూచిస్తాయి. రుసుము ప్రదాత, మోడల్, ఖాతా షరతులపై ఆధారపడుతుంది. BIG CHANGE ఈ ఫ్యాక్టరీ వ్యయం కొలవలేదు.

సక్రియ అమలుకు స్పష్టమైన ఆపే నిర్ణయమూ అవసరం. నియంత్రణ కోడ్ లో halt కొత్త ప్రారంభాలు, కొనసాగింపులు అడ్డుకుంటుంది; cancel <run-id> సక్రియ పనిని లక్ష్యంగా తీసుకుంటుంది. pause టైమర్ ప్రారంభాలు ఆపినా ఇప్పటికే నడుస్తున్న పని మేల్కొలుపులను అనుమతిస్తుంది. ఏ కమాండ్ కూడా ప్రస్తుత అమలు స్థితి, దూరపు రిపాజిటరీ మార్పులు చూడటానికి ప్రత్యామ్నాయం కాదు.

మూలాలు, అదనపు పఠనం