Skip to main content

Getting started

This page explains how to pick up and ship a ticket. The full workflow specification lives in workflow.md, this page is the operator's view.

The mental model​

You start with a ticket. You write code. You merge a PR. Jira moves the ticket through states automatically because your branch and PR carry the ticket key.

Steps where you act: pick the ticket, verify it's still real, write the code, review the PR.

Steps that happen automatically: status transitions in Jira when you push a branch with PS-XX in the name (moves to In Progress) and when a PR with PS-XX in the title merges to main (moves to Done).

The 6 steps​

Step 1, Pick a ticket​

Open the Pasar Seken Jira board (link in team onboarding doc). Pick from Backlog. Wave 1 tickets (PS-47 to PS-51) are the highest priority, start there.

Read the Acceptance Criteria. If anything is unclear, comment on the ticket asking for clarification before starting.

Step 2, Verify the ticket is still real​

Some tickets are marked LIKELY_OPEN, meaning the triage scan found a signal but didn't deeply verify the issue exists in current code.

Before implementing, grep the cited file at the cited line on pasarseken@origin/main. If the issue is already fixed, comment on the ticket: "Already fixed in commit [sha]. Closing as duplicate." Then close it.

Step 3, Branch off main with PS-XX in the name​

Always branch off origin/main. Never branch off develop.

cd ~/Desktop/Dev\ Projects/pasarseken
git checkout main && git pull
git checkout -b feature/PS-47-add-user-follows-migration

Within ~10 seconds of pushing the branch, Jira automatically moves PS-47 to "In Progress." You don't update the status manually.

Step 4, Implement the fix​

Write the code. Use Claude Code if it helps. Test locally if possible.

Commit messages must reference the ticket:

git commit -m "PS-47: add user_follows table migration"

Push the branch. Open PR #1 to develop, then PR #2 to main with the same source branch. This is the two-PR flow per pasarseken's CLAUDE.md.

Step 5, PR review and merge​

The Founder (or you) reviews the PR. Merge to develop first.

If the ticket is revenue-risk labeled, validate briefly on staging before promoting. Then merge to main.

The Playwright check is currently failing on every PR (known issue, fix in PS-57). Override with comment: Override per PS-57 — known stale test design. Don't let it block your work.

Step 6, Ticket auto-closes​

Within ~10 seconds of merging the PR to main, Jira moves the ticket to Done.

Add a comment to the closed ticket confirming you verified the change works in production. This is "Done-Done", the work isn't truly finished until verified.

Key rules​

No work without a ticket​

Every branch starts with PS-XX. Every commit references it. PR titles include it. If you find yourself wanting to write code without a ticket, file the ticket first.

Branch off main, not develop​

Always cut from origin/main. The two-PR flow (develop → main) exists to validate before production. Branching off develop bypasses validation.

Brain is the source of truth​

Decisions, signals, and workflow rules live in pasarseken-ai-brain. If something is unclear in pasarseken or here, check the brain first. The canonical workflow spec is at workflow/jira-integration.md in the brain.

Revenue-risk gets extra eyes​

Tickets labeled revenue-risk touch payments, payouts, escrow. Test thoroughly on staging. When the PR Reviewer agent goes live (week 2-3 of the EOS plan), it will run a security checklist on these tickets automatically. For now, the security checklist is on you.

When stuck, file a signal not a fix​

If you find a new bug while working on a ticket, don't expand scope. File a new ticket with what you found and continue with the original work. The signal collector or you will pick it up later.

What the EOS will do for you (in time)​

The Engineering Operating System (workflow/eos-design-2026-04-29.md in brain) describes 6 agents that will progressively automate the parts of this workflow that don't need a human:

  • PR Reviewer: checks ticket alignment, security, scope on every PR (week 2-3)
  • Architecture & Code Health Guardian: catches duplicate implementations, code rot (week 3)
  • Alignment Auditor: weekly check that locked decisions are reflected in code (week 7)
  • Signal Collector: daily Sentry + support ticket digest (week 8)
  • Backlog Gardener: weekly re-verify of LIKELY_OPEN tickets (week 5)
  • Release Readiness: pre-release security/observability/rollback checklist (week 9)

All agents are advisory. They surface issues. Humans always decide.

When something feels off​

The system is fresh. If something doesn't match this page, or feels wrong, tell the Founder. Today's session already surfaced one structural gap (Obsidian Git auto-commit bypassing brain governance). Your gut check matters.

For incidents in production (payment broken, payout failed, auth down): see the rollback runbook at workflow/runbooks/rollback.md in the brain repo.