Logování pracovního dne z podkladů v gitu

Sledování času je ten typ otravné povinnosti, která se dělá v šest večer z paměti, a špatně. Podklady o tom, co jsem skutečně dělal, už existují — commity, pull requesty, události v kalendáři —, takže jsem napsal agentní skill, který je čte a zapisuje den do 7pace Timetracker, nástroje, který používá naše organizace v Azure DevOps. Tady je jeho podoba a pravidla, díky kterým je důvěryhodný.

Pipeline

1. Posbírat podklady. Commity a pull requesty za daný den z Azure DevOps (přes az CLI, protože jeho --query vrací jen ta pole, o která požádáš), schůzky z publikovaného kalendářového feedu.
2. Sestavit plán. Schůzky zůstávají na svých místech podle kalendáře; pracovní bloky vyplní mezery a namapují se na work itemy, které stojí za commity. Granularita půl hodiny, typický den osm až devět hodin, jeden typ aktivity na blok.
3. Zobrazit jako tabulku. Časový rozsah, work item, hodiny, aktivita, komentář.
4. Počkat na explicitní „jedeme“. Nic se nezapíše, dokud to neřeknu, a opravy se vrací zpátky ke kroku 2.
5. Zapsat a ověřit. Položky jdou přes 7pace MCP server, nebo pokud na daném počítači chybí, přes Node skript bez závislostí, který dělá stejná volání.

Tvrdá pravidla

Soubor skillu obsahuje hrstku pravidel v prostém jazyce a ta odvedou víc práce než jakékoli množství kódu:

• Worklogy jednoho dne se nikdy nesmí překrývat. Položky jdou přísně jedna po druhé.
• Nikdy nezapisovat bez schválení.
• Nikdy nelogovat do budoucnosti. V aktuální den nesmí žádný blok končit později než „teď“.
• Interní schůzky nemají work item. Schůzky k misi jdou na epic dané mise.
• Nikdy nevypisovat ani necommitovat token.

Pravidlo o překryvu navíc vynucuje i skript, který plán s překryvem rovnou odmítne. Pravidlo, které čte model, a kontrola, kterou provádí kód, nejsou nadbytečné: první brání většině chyb, druhá odchytí zbytek.

Co se musel nástroj naučit

Původní MCP server nedokázal na naší instanci zalogovat jedinou položku. Typy aktivit se vracely ve tvaru, který neuměl parsovat, takže posílal worklogy bez nich a API je odmítalo; heuristika měnila patnáctiminutové položky na patnáctihodinové; endpoint pro výpis ignoroval své filtry na datum. Udělal jsem fork a opravil to, pak přidal dvě věci, které pipeline skutečně potřeboval: nepovinný čas začátku, aby šlo položky rozložit sekvenčně, a nepovinný work item, protože schůzky ho nemají. Pravidlo o zákazu překryvu putovalo do popisu nástroje — tam, kde ho model čte předtím, než ho zavolá.

Co bych řekl někomu, kdo staví totéž

• Dejte pravidla tam, kde je model uvidí ve chvíli rozhodování: do popisu nástroje a do skillu, ne do README.
• Nechte nástroj selhávat nahlas. Neznámý typ aktivity by měl vypsat platné možnosti, ne tiše zahodit pole a nechat API odpovědět nesrozumitelnou chybou 400.
• Držte schvalovací bránu na každém zápisu. Čtení podkladů je zadarmo, zápis worklogů ne.
• Tajemství držte mimo repozitář: .env.example uvnitř, .env v gitignore a kontrola ve skriptu, která odmítne spuštění se zástupným tokenem.

Výsledkem je pár minut denně místo rekonstruovaného odhadu a záznam, který odpovídá tomu, co podle repozitáře skutečně proběhlo.