Одобрена функционалност може да прође кроз три система пре него што буде завршена: документ са захтевима, хијерархију ставки у Jira и репозиторијум. Claude Code може да помогне у писању и имплементацији, али везе између тих система захтевају људско одобрење и непосредне провере. Овај водич води програмера или вођу тима кроз једну стварну функционалност, укључујући сваку одобрену причу, њене изворне тестове, овлашћена ажурирања у Jira и прегледану одлуку о пројектним смерницама.

Ово је поступак заснован на документацији. BIG CHANGE није приступао Jira пројекту, покретао Claude Code, мењао репозиторијум нити мерио време испоруке функционалности. Тачни типови ставки, поља, прелази, команде и трошкови зависе од вашег пројекта и налога.

Велика промена

  • Шта се променило: Функционалност се може пратити од одобреног захтева, преко стварне надређене Jira ставке и сваке приче, до прегледаног кода, изворних провера и овлашћених ажурирања ставки.
  • Зашто је важно: Мапа ставки, записи о тестовима и подаци поново прочитани непосредно из Jira показују који је одобрени посао завршен, а која прича је још отворена.
  • На шта обратити пажњу: Поља и прелази специфични за пројекат, уписи неизвесног исхода и неуспеле провере захтевају људско разрешење; смернице за Claude Code саме по себи не дају овлашћење за рад.

Пре почетка

Изаберите функционалност са описом који је одобрио одговорни власник, репозиторијумом који смете да мењате и изворном провером прихватљивости коју можете да покренете. Стварни посао мора да оправда једну надређену ставку на нивоу епика, њене одобрене приче и бар један смислен подзадатак у оквиру приче у изабраном Jira Cloud пројекту. Ако нема стварног подзадатка, овај конкретни целовити исход остаје недовршен; додавање украсне ставке би искривило план. Забележите подносиоца захтева, овлашћење за одобравање, ревизију извора, дозвољене податке, почетни Git commit, начин изолације или враћања и особу која сме да прегледа код и мења Jira статус.

Проверите инсталирану верзију Claude Code, аутентификацију и дозволе. Потврдите да датотека CLAUDE.md у репозиторијуму даје пројектне смернице, али не даје дозволу за измене, покретање команди или слање података. Одредите које захтеве и код Claude сме да добије, које команде сме да покрене и ограничење употребе за ову функционалност. Употреба Claude Code може да троши претплатничку квоту или направи трошкове код добављача; Anthropic водич о трошковима не утврђује ваш рачун унапред.

За Jira прибавите дозволу да прегледате и правите одговарајуће типове ставки, а касније да као овлашћени корисник коментаришете или мењате њихов статус. Приватна скрипта може да користи поступак са имејлом и API токеном из Atlassian документације; интеграцији може бити потребан OAuth. Чувајте акредитиве у приватном складишту тајни. Не уносите их у упите, текст ставки, CLAUDE.md, евиденције или систем контроле верзија. Договорите видљивост ставки пре слања захтева у Jira.

Током рада чувајте седам приватних евиденција: docs/feature-prd.md, ticket-plan.json, дневник уписа ставки у који се само додају записи, ticket-map.json, по једну потврду имплементације за сваку причу, дневник Jira ажурирања и одлуку након осврта. То су записи о вашој функционалности, а не датотеке које је BIG CHANGE обезбедио или извршио.

1. Одобрите један тачно одређен PRD

Дајте Claude Code стварни одобрени опис функционалности и затражите да утврди нерешена питања пре писања docs/feature-prd.md. Документ треба да садржи подносиоца и власника који одобрава, ревизију улаза, проблем и намењеног корисника, обим и изузетке, нумерисане идентификаторе захтева, провере прихватљивости и изворе доказа, нефункционална ограничења, Jira пројекат и отворена питања. Одговорна особа треба да упореди нацрт са изворним описом и одобри једну тачну ревизију садржаја и њен хеш. Решите битна питања пре прављења ставки или мењања кода.

Хеш даје каснијим записима прецизан извор. Ако се PRD промени, поново прегледајте погођени план ставки и провере; неуспех имплементације није разлог да препишете критеријуме прихватљивости тако да резултат буде пролазан.

2. Утврдите Jira хијерархију и поља овог пројекта

Помоћу овлашћених захтева само за читање ка Jira REST API v3, прођите кроз све странице GET /rest/api/3/issue/createmeta/{projectIdOrKey}/issuetypes. За сваки предложени тип ставке прођите кроз све странице GET /rest/api/3/issue/createmeta/{projectIdOrKey}/issuetypes/{issueTypeId} да утврдите обавезна поља за креирање и дозвољене вредности. Atlassian означава широку операцију GET /issue/createmeta као застарелу у својој референци API-ја за ставке.

Потврдите стварну надређену ставку еквивалентну епику, подређене ставке на нивоу приче и подржане подзадатке за овај пројекат. Atlassian описује подразумевану хијерархију и њено подешавање; називи типова и ID вредности нису универзални. Проверите како поље Parent у пројекту ради за сваки подређени ниво и која прилагођена поља или подешавања видљивости захтева креирање. Ако пројекат не може да представи одобрену структуру, забележите тип, поље или дозволу која недостаје и обуставите креирање. Обична веза између ставки не ствара однос родитељ–дете.

3. Прегледајте цео план ставки пре уписа

Повежите сваки PRD захтев и проверу прихватљивости у ticket-plan.json. Забележите његов planVersion, PRD хеш, Jira сајт и кључ пројекта, локални ID извршавања и особу и време одобрења плана. За сваку предложену ставку забележите јединствен локални ID, планирани локални ID родитеља, утврђени ID типа ставке, обавезна поља пројекта, сажетак, опис, идентификаторе захтева и прихватљивости, власника и дозвољену видљивост. Одобрени посао одређује број прича и подзадатака. Сваки подзадатак мора да обавља стварни посао у оквиру своје праве приче.

Jira REST v3 користи Atlassian Document Format (ADF), структурирани JSON документ, за вишередне описе ставки и коментаре. Припремите те документе из одобреног садржаја и проверите метаподатке поља које сајт враћа пре формирања сваког захтева. API за ставке документује креирање; не може да испоручи готов објекат поља за непознати пројекат. Особа треба да одобри целу структуру, покривеност свих захтева, надређене односе и тачно одредиште уписа пре било ког POST захтева.

4. Прво креирајте родитеље и поново прочитајте сваку ставку

Креирајте одобреног родитеља путем POST /rest/api/3/issue, затим његове приче, па сваки стварни подзадатак. Пре сваког захтева додајте приватни запис у дневник: ID извршавања, локални ID ставке, потврђени кључ родитеља када је применљиво, одредиште, хеш тачно одобреног захтева, UTC време покушаја и стање pending. Не укључујте токен. После HTTP 201 забележите ID и кључ ставке које Jira врати, па директно позовите GET /rest/api/3/issue/{issueIdOrKey}. Упоредите пројекат, тип, сажетак, опис или PRD референцу и родитеља са одобреним планом. Означите запис као confirmed тек после тог поновног читања. Потврђен родитељ омогућава креирање његове деце.

Ако захтев истекне или се одговор изгуби, означите га као unknown. Проверите Jira према пројекту, времену, одобреном сажетку и референци плана, затим непосредно отворите могући погодак и затражите да овлашћени власник утврди његов идентитет. Atlassian упозорава да претрага после уписа може да касни. Одсуство резултата претраге није доказ да креирање није успело. ID извршавања и дневник помажу у усаглашавању, али не приморавају сервер да одбије дупло креирање. Никада не понављајте наслепо POST чији је исход неизвесан.

Непосредно прочитајте завршену структуру у ticket-map.json: сваки локални ID, стварни Jira ID и кључ, канонски URL ставке, пројекат, тип, кључ родитеља, PRD идентификаторе и идентификаторе прихватљивости, време поновног читања и референцу дневника. Упоредите све одобрене ставке и критеријуме са PRD-ом. Зауставите даље уписе ако ставка недостаје или има погрешног родитеља; користите прегледани поступак исправке пројекта.

5. Имплементирајте и независно прегледајте сваку одобрену причу

Радите одобрене приче по редоследу зависности. За сваку забележите Jira кључ, почетни Git commit и грану или радно стабло, изворну команду за прихватљивост, дозвољене путање и команде. Затражите од Claude Code да употреби Plan mode да повеже критеријуме те приче са репозиторијумом. Програмер проверава план и одобрава ограничену измену. Граница приче чини измену прегледном; не уклања преостале одобрене приче из функционалности.

После измене сачувајте тачан diff, изворну команду провере са целим излазом и излазним статусом, релевантне циљане тестове и оцену за сваки идентификатор захтева. Прегледајте стварни код и евиденције. Писани план, генерисане датотеке или Claude тврдња да су тестови прошли нису доказ да измена ради. Обуставите причу при неуспелој провери, неочекиваној тајни, промени зависности, спољном упису или широком рефакторисању; поправите у одобреном обиму и поновите изворну проверу. Други прегледач кода одлучује да ли прихвата настали commit или задржава diff на чекању. Забележите ту одлуку за сваку причу. Наш ранији водич за једну прегледану измену помоћу Claude Code покрива ужу фазу прегледа кода; PRD и цела Jira структура овде дају ширу границу функционалности.

6. Потврдите овлашћена Jira ажурирања

За сваку прегледану причу прочитајте тренутни Jira статус и затражите GET /rest/api/3/issue/{key}/transitions?expand=transitions.fields. Проверите прелаз који је стварно доступан том кориснику, његово одредиште, обавезна поља и дозвољене вредности. Овлашћени власник затим може да пошаље изабрани прелаз путем POST /rest/api/3/issue/{key}/transitions са вредностима поља утврђеним за пројекат. Поново непосредно прочитајте ставку и потврдите нови статус. Пролазна провера кода сама по себи не овлашћује Done, спајање или постављање у рад.

Забележите статус пре уписа, планирани прелаз, корисника, захтев и одговор у дневник Jira ажурирања. Поставите чињенични ADF коментар са доказима путем POST /rest/api/3/issue/{key}/comment: прихваћени commit или задржани diff, изворна провера и циљани тестови, преостали неуспеси и одлука прегледача. Поново прочитајте ID и текст направљеног коментара из Jira API-ја за коментаре. Ако је одговор било ког уписа неизвесан, непосредно проверите статус или коментаре пре разматрања новог захтева. Празна листа прелаза или недоступно обавезно поље јесу недостатак у току рада или дозволама који треба решити са власником пројекта, а не позив да измислите ID.

7. Одлучите да ли CLAUDE.md треба мењати

Упоредите стварне PRD, ставке, diff, тестове, прегледе и Jira дневнике. Затражите од Claude кратак осврт који указује на уочена неразумевања или недостајуће провере. Особа бира прецизну измену смерница или бележи одлуку да нема измене, уз прегледача и време. Ако је одобрено, прегледајте и направите commit само за diff датотеке CLAUDE.md и његов хеш. Anthropic водич о меморији описује пројектне смернице; овај преглед не одобрава аутоматски будући рад. Не додајте тајне и не претварајте нагађање у правило пројекта.

Завршетак и опоравак

Функционалност је завршена само када одобрена PRD ревизија одговара директно потврђеној структури епика, прича и подзадатака; свака одобрена прича има почетно стање, прихваћени diff, доказе изворне провере и циљаних тестова и независан преглед; сваки овлашћени Jira прелаз и коментар са доказима непосредно су поново прочитани; и особа је донела одлуку о осврту. Забележите тачну преосталу фазу ако нешто недостаје. Избор првог AI задатка завршава се раније, избором задатка и предложеном провером; не доказује овај резултат имплементације.

Неизвесно креирање у Jira остаје unknown док особа не усагласи његов идентитет. Погрешан родитељ зауставља креирање деце. Неуспели тестови задржавају изворне критеријуме. Недостајући прелаз или исцрпљена квота остављају датиран делимичан запис за власника. Сведите захтеве и податке клијената на одобрени минимум за Claude и Jira, проверите тренутне трошкове и дозволе налога и планирајте људски преглед кода. Водич документује условни пут кроз алате; не извештава о функционалности коју је BIG CHANGE завршио, Jira упису, покретању модела, измереној уштеди, спајању или постављању у рад.

Извори и даље читање