Frinks AI · Two-week release cycle

Frinks Release Timeline

One release, ten working days. Days 1–7 are development. PRDs are due on day 6 and code freezes on day 7. Days 8–10 are release sanity: Swayam fixes bugs with Vaibhav overseeing, while Sagar plans the next release. Days −4 to 0 are planning for this release, held during days 6–10 of the previous one. Each day lists every person's tasks for that day.

Checkpoints Day −4 to day 11

Guidelines for Sagar

Project Manager

Lead the Release Sync every day (6:30–7 PM). All discussions about release planning and progress happen here; on days 1–7 it only tracks release progress.
Join the Product Sync with Akshat and Vaibhav every day, 11:30 AM–12:30 PM: updates from yesterday and plan for today. If Vaibhav is not available, send the daily update as a message.
Be on every call that involves Vaibhav and the devs. Book these calls around the devs' availability.
Take PRDs on any day. Day 6 (day −4 for this release) is the deadline to take all PRDs from Vaibhav.
Send project-wise mails every day.
You alone create the tickets. Start on day 7 and close on day 8, the deadline (days −3 and −2 for this release).
Write every ticket clearly enough that no dev discussion is needed.
Keep count of PM–dev discussions about the current release's tickets. Each one means the PRD or ticket wasn't clear enough. Discussions to scope future tickets aren't counted.
On day −3, the Product Sync covers the gists: Vaibhav explains each PRD to you and Akshat, and Akshat walks you and Vaibhav through the enhancement whitepapers.
Devs bring their doubts on tickets to you, not to Vaibhav.
Know what each dev is working on and how loaded each dev is, and in release planning distribute tasks so that every dev is occupied.
In release planning, give each dev 10 days' worth of work. Only what is merged by day 7 is released.
Lock the list with Commit Items, which must ship, and Buffer Items, picked up if a dev is free. A successful release means all Commit Items are released without any bugs.
Lock the list by day 9, the deadline (day −1 for this release). On day 10 (day 0), the Product Sync reviews it, adds items as needed, and decides whether the release is major or minor.
On days 6–7, run pre-merge testing: test each ticket after its PR review and before it merges, and send NOKs back to development.
Give your sign-off on testing by day 7, the deadline.
On days 1–6, add the enhancement tickets from Akshat to the current sprint.
On day 7, create an instance on the QA env for main testing and screenshot grabbing. The instance, its dashboards and everything else on it must not reveal any client's name: these screenshots go straight into the release notes and manuals, so name everything with care.
On day 8, do the Internal Release Check: show Vaibhav the working demo of the release.
On day 9, read out the release notes draft with Vaibhav and Akshat in the Product Sync, and note the devs' leaves before the next release starts.
Join Akshat's Ops Team Sync (7–7:30 PM) every day, including days −4 to 0, and take it yourself when Akshat is on leave.
On day 11, the release demo happens in the Ops Team Sync.
If the release slips into day 11, start the next release on day 11 anyway.

Guidelines for Akshat

Associate PM

Lead the Ops Team Sync (7–7:30 PM) every day, with Sagar, including days −4 to 0.
On day 11, demo the release to Dharmgya, Vaibhav, Sagar and the Field Team in the Ops Team Sync (7–7:30 PM).
Write enhancement PRDs every day: for the current sprint on days 1–4, and for the next sprint from day 5. Enhancement requests received by day 4 are closed in the running release; later ones go into the next release.
You are the only contact for Ops POCs. Vaibhav doesn't contact them, and Sagar takes the Ops Team Sync when you are on leave.
Create the Ops report every day, including days −4 to 0.
Attend Ops issues calls every day, as they come up.
Join the Product Sync with Sagar and Vaibhav every day, 11:30 AM–12:30 PM: updates from yesterday and plan for today. If Vaibhav is not available, send the daily update as a message.
On day −3, in the Product Sync, give Sagar and Vaibhav the gist of all the enhancement whitepapers you wrote. Vaibhav gives the PRD gists in the same sync.
Discussions with devs about the current release's tickets shouldn't be needed. If one happens, the PRD or ticket wasn't clear enough, and Sagar counts it.
On day 9, read out the release notes draft with Vaibhav and Sagar in the Product Sync.
Join the Release Sync (6:30–7 PM) every day, including days −4 to 0, so you can take charge when Sagar is out.

Guidelines for Vaibhav

Hand PRDs to Sagar on any day. Day 6 (day −4 for this release) is the deadline to finalise the PRDs for the next sprint and hand them over to Sagar.
PRD writing and research is your daily task, except on day −4.
Write PRDs only. Don't create tickets; Sagar creates all of them.
On day −3, in the Product Sync, explain each PRD to Akshat and Sagar. Akshat gives the gist of the enhancement whitepapers in the same sync.
Lead the Product Sync with Sagar and Akshat every day, 11:30 AM–12:30 PM: updates from yesterday and plan for today.
Lead the Field Team Sync (12:30–1 PM).
On days −4 to 0, also attend the Release Sync (6:30–7 PM) and the Ops Team Sync (7–7:30 PM).
Discussions with devs about the current release's tickets shouldn't be needed. If one happens, the PRD or ticket wasn't clear enough, and Sagar counts it. Discussions to scope future tickets are fine.
Don't discuss anything with a dev unless Sagar is also on the call.
Don't contact Ops POCs. They go only through Akshat, or Sagar when Akshat is on leave.
Devs bring ticket doubts to Sagar. They come to you directly only when Sagar is on leave.
On day 10 (day 0 for this release), review the locked list in the Product Sync, add items as needed, and decide whether the release is major or minor. Hotfixes go out ad hoc.
Oversee release sanity and bug fixes through days 8–10. Check in with Swayam only when needed; it is not a daily meeting.
On day 8, do the Internal Release Check: review the working demo of the release with Sagar.
On day 9, read out the release notes draft with Akshat and Sagar in the Product Sync. Finalise the notes on day 10 with the screenshots and your tweaks.
Send the release with Swayam on day 10 by EOD.
If the release slips into day 11, finish it with Swayam while Sagar starts the next one.

Guidelines for Swayam

Release dev

Merge only the tasks listed in a ticket under that ticket. Never merge other tickets' tasks under a common ticket.
Close testing and the PR review within days 6–7.
Day 7 is the merge deadline. Code freeze is at day 7 EOD.
Take any doubt on a ticket to Sagar, not Vaibhav. Contact Vaibhav directly only when Sagar is on leave.
Discussions with Vaibhav are only for scoping future tickets, and Sagar books them.
Join the Release Sync (6:30–7 PM) every day.
Trigger Claude main testing once the test cases are vetted.
Own the fixes for every issue found in days 8–10. Retests run within the existing testing flow.
Check in with Vaibhav on release sanity only when needed; it is not a daily meeting.
If the release slips into day 11, finish it with Vaibhav.
Deb makes the release when you are unavailable.

Guidelines for Devs

Software Development Team

Build Commit Items first. Pick up Buffer Items if you are free.
Every ticket must have its test cases written in it.
Merge only the tasks listed in a ticket under that ticket. Never merge other tickets' tasks under a common ticket.
Close testing and the PR review within days 6–7.
Day 7 is the merge deadline. Code freeze is at day 7 EOD.
Fix every issue found in days 8–10 within the same window.
On days 8–10, work on the tickets that missed the day 7 merge.
Join the Release Sync (6:30–7 PM) every day.
Take any doubt on a ticket to Sagar, not Vaibhav. Contact Vaibhav directly only when Sagar is on leave.
Discussions with Vaibhav are only for scoping future tickets, and Sagar books them.

Part 2

Release Flow

Release nomenclature and the eighteen steps every release passes through. Each step is tagged with the day on the timeline above when it happens. After merge, the test cases and release notes are created and the internal snapshot is taken. The flow then splits into a test case branch and a release notes branch, which meet when the release notes are finalised.

Release nomenclature

Decided

26Year . 2Major . 3Minor . 1Hotfix

Read 26.2.3.1 as: the 2nd major release line cut in 2026, its 3rd minor release, and the 1st hotfix on top of that minor. A normal release stops at three numbers: 26.2.3. The fourth number appears only on a hotfix.

Slot	Name	What it means	Compatibility	Code tester	Migration
26	Year	The year the major line was cut, not when a build shipped. A fix to `26.4` released in Feb 2027 is still `26.4.x`. The first release with a `27` prefix is always a major.	Informational only	—	—
.2	Major	Big enhancements, new modules, schema / key / config changes.	When scripts at Edge are updated across a change in this number, the user must download a new version of the instance from Vision.	Full	Yes. This is the only slot where migrations are allowed.
.3	Minor	Small bugs and leftovers. May be urgent, never breaking.	Always compatible within the line. Vision and Edge may differ here.	Full	No
.1	Hotfix	Panic fix, shipped in 1–2 days. A normal release is `26.2.3`; a hotfix on it is `26.2.3.1`. Never write `26.2.3.0`.	Always compatible. Vision and Edge may differ here.	—	No

The eighteen steps

2 branches · 6 decision points

PMVaibhavSAGARProject ManagerDEVSwayam or the ticket's devCLAUDEa Claude skill

Development and PRs run on days 1–5. PR review and pre-merge testing run on days 6–7, and merge on day 7. Steps 01–10 run in sequence up to the internal snapshot on day 8. The flow then splits into test case review (11a) and release notes review (11b). Main testing (12a) and adding screenshots to the notes (12b) sit in one box, and steps 13–15 follow in the centre. The notes are finalised at 16. Green is the approved path and orange shows the ways back. Boxes outlined in orange are the review points. The small line under each step is the day it happens on, matching the timeline above.

Discussion PM + Dev days 1–6, release before

All PM–dev discussion about the tickets for the next release happens here.
All dev clarity is set in these discussions.

Ticket creation Sagar Claude · Skill · ticket-creation days −3 and −2

Only Sagar creates tickets, based on the PRDs sent by Vaibhav and Akshat.

Release planning Sagar days −3 to 0

Sagar discusses with the devs which tickets to assign to whom, and in what priority.

Development Dev days 1–5

Devs start work on the stories and sub-tasks.
PM interaction is kept to a minimum in this period. To make that possible, tickets are written with the utmost clarity.
Development is test-driven: the tests are written before the code, and the code is written to pass them. Work in this order, in every repo the ticket touches:
1. Understand and map. Read the requirement, then map it onto the repo: which modules, APIs, screens and data each executional touches.
2. Write the tests. With the help of AI agents, write complete automated test code in the repo, covering every executional and every acceptance criterion. Move on only when you are satisfied that the tests describe the whole requirement. At this point the tests fail, because the feature does not exist yet.
3. Write the code. Use Claude to write the code against those tests. Making every test pass is your responsibility, not Claude's.
4. Add technical tests. Once the code is written, add tests that are about the code rather than the user journey: error handling, invalid input, a failing dependency, and code-level issues.
5. Run everything. The whole test suite of each repo passes.
If a test turns out to be wrong, fix it on purpose and say why in the PR. Never change a test only to make it pass.
In the ticket's Dev test cases section, note where the tests live and which executional (E1, E2) each one covers.
Build Commit Items first; pick Buffer Items only when free.
Where a migration is needed, maintain a migration script, with tests for it. Upgrades run one version at a time until the latest is reached.
One branch per ticket, named with the ticket key first, for example FP-3535-sector-python, with the same name in every repo the ticket touches. Never delete a branch.
If you need something the ticket does not say, or cannot write a test because the requirement is unclear, ask the project manager to update the ticket first.
Done when: all five steps are done in every repo the ticket touches. Do not raise a PR or open the PR review page before this.

PR raised per ticket Owner: the ticket's developer days 1–5

Raise the PR only once step 04 is done: the tests, including the technical ones, are written and pass. The PR carries the tests and the code together.
One PR per ticket (per repo), with the ticket key in the title. Each ticket's changes go in that ticket's own PR.
Sign in to the Release Manager with GitHub before you act: reviews and merges are recorded under your name.

PR review Done by Claude (PR vetting skill) · started by the ticket's developer Claude · Skill Decision point days 6–7

Claude's review

On the Pull Requests page, run Claude's review for the whole ticket.
Claude reads the Jira ticket, the tests and the code. It checks that every acceptance criterion has a test, that each test really checks the behaviour, and that the technical tests are there. It also looks for gaps between Jira and the code, and for migration gaps.
R&D and discussion tickets are not vetted.

Developer's review

The developer who owns the ticket reviews the report. The PM is brought in only when it is urgent.
Read every finding. Fix the real ones and run the review again; use the follow-up box to ask Claude about a finding you do not understand.
Whoever reviews the PR reads every test case in it, not only the code. Missing or weak tests make the ticket NOK, even when the code looks right.
NOK → back to development (04).
OK → sign off the ticket on the PR page. If findings are left open on purpose, the sign-off needs a note saying why. A new commit or a new review cancels the sign-off.

Pre-merge testing Owner: Sagar Decision point days 6–7

Sagar tests the release code on the QA environment before giving the sign-off for merging.
NOK → back to development (04). OK → merge (08).

Merge Owner: the ticket's developer day 7

Merge the ticket's PR once its PR review is OK and Sagar has signed off pre-merge testing, only through the Release Manager (merge commit, never squash).
Merge only the tasks listed in a ticket under that ticket.
Day 7 is the merge deadline. Before it, check What is going out: every ticket shows a review and a sign-off. Testing and the PR review close by day 7, and the project manager signs off testing.

Test cases + release notes created Claude · Skill day 7

Test cases

The tickets' acceptance criteria are used to make the test cases. The PM vets them (11a).
Claude's skill dedups similar test cases and creates new ones from its understanding of the ticket and the code.

Release notes

The tickets' release notes sections are used to create them.
Claude's skill dedups similar release notes and creates new ones from its understanding of the ticket and the code.

Internal release snapshot Release dev day 8

Code freezes at the end of day 7. The release dev cuts the branch and takes the snapshot in the Release Manager:
1. Create Release, step 1: repo releases. “Fill from latest notes” fills them from the technical notes.
2. Create Release, step 2: the release candidate, for example 26.2.3-rc1.
Everything that follows runs against this one snapshot.

Test case branch

Steps 11a, 12a and 13–15.

11a

Test cases reviewed PM Decision point day 8

NOK → tweak by prompt: the PM adds, changes or removes cases and the set is reviewed again. No ticket or code change is involved.
OK → main testing starts.

12a

Main testing Triggered by the release dev Claude · Skill days 8–9

Once the test cases are reviewed, the release dev triggers Claude main testing on the snapshot.

Test report generated Claude · Skill day 9

Main testing produces a testing report.

Test report reviewed Release dev Decision point day 9

OK → the release notes can be finalised (16).
NOK → the gaps are shown, and the call is made at 15.

Halt or ship decision PM + Dev Claude · Skill day 9

Halt the release → back to development (04) for fixes. The fixes come back through the same flow and are retested on a new snapshot. The release dev owns fixes and retests, and the PM oversees them.
Ship with the bugs as known issues → on to step 16.
Bugs are created automatically at this step, whichever way the call goes.

Release notes branch

Steps 11b and 12b. Screenshots are added right after main testing.

11b

Release notes reviewed PM, Akshat, Sagar Decision point day 9

Vaibhav, Akshat and Sagar read the draft out in the day 9 Product Sync.
NOK → tweak by prompt: wording, ordering or coverage. OK → the draft waits for the test result.

12b

Add screenshots to release notes Claude · Skill day 9

Runs right after main testing (12a), not after the test report.
Claude captures the screens named in the image placeholders from step 02, on the snapshot, and adds them to the draft reviewed at 11b.
The screens come from the QA env instance Sagar sets up, which carries no client names.

Finalise and ship

Steps 16–18.

Release notes finalised PM reviews Claude · Skill Decision point day 10

Runs once the test report is OK (14), or once the decision is to ship with known issues (15).
The PM makes the final tweaks to the notes, with their screenshots (12b) and any known-issue bugs (15).
NOK → prompt-based tweaks only: wording, ordering, or swapping an image. The test report is already approved at this point, so nothing here goes back to a ticket or to code.
OK → publish.

Release, files and notes published PM + release dev day 10 EOD

Vaibhav and Swayam send the release on day 10 by EOD. Deb covers when Swayam is out. If it slips to day 11, they finish it while Sagar starts the next release.
Three things go out together: the release, the release files (the scripts bundle for the installer) and the release notes.
When scripts are updated at the installer, a DB backup is taken. It covers a release that goes bad and is the restore point for a rollback.
Plants update on their own schedule. Updating the bundle requires pulling the matching instance version from Vision.

Manuals updated PM reviews Claude · Skill after the release

A separate skill updates the manuals once the release is out.
The source is the ticket executionals, so manuals and release notes describe the same change.

Claude skills this needs

1 existing · 5 new

Stage	Skill	Status	Reads
02	ticket-creation	Exists	A PRD, run by Sagar → tickets, fix version, note text, image placeholders
06	PR review	New	The Jira ticket + the code in the PR
09 · 12a · 13	Testing	New	Tickets, the snapshot, the approved test cases
15	Bug creation	New	Gaps from the test report
09 · 12b · 16	Release notes	New	Draft: ticket note text. Then screenshots from the snapshot and known-issue bugs
18	Manuals update	New	Ticket executionals

Steps 01, 03, 04, 05, 07, 08, 10, 11a, 11b, 14 and 17 involve no Claude skill.

Hotfix releases

Panic path

Quick discussion between the PM or Sagar and the dev.
Development.
PR creation.
PR review (can be skipped).
Internal release snapshot.
All further steps are skipped, and the release goes straight to production.