Team Workflow

Internal page, do not share publicly.

This is a summary. The full canonical spec lives in the SEKEN AI Brain repo (pasarseken-ai-brain). When something here is unclear or seems out of date, defer to the brain.

The rule: Signal → Ticket → Work

Every change to the SEKEN product follows three stages, in order:

1. Signal. A bug, gap, risk, or opportunity is identified, usually surfaced from the brain (raw notes, transcripts, audits, observations).
2. Ticket. The signal becomes a draft Jira ticket in project PS (Pasar Seken). Drafts land in the project's initial state ("To Do", the brain's "Backlog" equivalent). They are unassigned, unscheduled, and waiting on a human.
3. Work. A human triages the ticket, sets priority, and approves it for execution. Only then does anyone create a branch, write code, or change the product.

No Signal? Don't open a ticket.

No Ticket? Don't write code.

No human approval on the ticket? Don't merge.

This rule applies to product engineering, design, ops automations, finance integrations, and infrastructure work alike.

Where signals come from

• The brain (most signals). The Founder and the AI extract unresolved items from raw notes, audits, and analyses on a regular cadence. See scripts/extract-and-push.md in the brain repo.
• Production incidents. Anything customer-facing or financial that breaks gets a ticket immediately, even if it's already being fixed.
• Strategic decisions. Decisions captured in the brain that imply product changes spawn tickets.
• the Engineer's weekly update. Technical decisions and findings ingested into the brain may surface new signals.

How tickets are created

• By the brain (most cases). The extract-and-push workflow drafts tickets and pushes them via the Jira REST API. Every brain-originated ticket carries the brain-ai-source label and a brain-source reference in its description.
• By a human. Anyone on the team can create a PS ticket directly in Jira. Apply the same labels and follow the same description structure (Context / Expected / Affected / Acceptance Criteria).

Ticket structure

Every PS ticket includes:

• Summary: short, imperative.
• Type: Task (default), Epic, or Subtask. The PS project does not have Bug or Story types; bugs are filed as Task with the bug label.
• Priority: Lowest / Low / Medium (default) / High / Highest.
• Labels: controlled vocabulary (see below).
• Description with sections: Context, Expected, Affected, Acceptance Criteria, Brain-AI Source (if applicable).

Allowed labels

Domain: bug, feature, payments, auth, seller-flow, buyer-flow, chat, search, listing, onboarding, infra.

Risk: revenue-risk, mandatory for anything touching payments, escrow, refunds, fraud, margin, commission, payouts, disbursements, or Xendit.

Operational: test, brain-ai-source.

Don't introduce new labels without updating the brain spec.

Branching, commits, and PRs

When a ticket is approved and ready to execute:

• Branch naming: every branch name MUST contain the PS-XX ticket key. The exact prefix vocabulary (e.g. feature/, fix/, chore/), naming pattern, and base branch are owned by each consumer repo's own Git workflow, see that repo's CLAUDE.md or equivalent for local rules.
• Commit messages: every commit MUST reference PS-XX in the subject so Jira links the commits to the ticket. Example: feat(seller-dashboard): PS-103 add bulk listing import.
• PR title: must start with PS-XX.
• PR description: must link to the Jira ticket (your team's Jira board URL, e.g. https://[workspace].atlassian.net/browse/PS-XX).
• Base branch / merge target / single-PR vs two-PR flow: owned by the consumer repo. The brain does not prescribe these, defer to the repo's existing Git workflow.
• Merging: reviewer confirms the ticket exists, is in an approved state, and the work matches the acceptance criteria. No green-light, no merge.

Roles

Role	Responsibility
Founder	Triages tickets in Jira, sets priority, decides what gets worked on. Owns the brain.
Engineer	Implements approved tickets. Surfaces new signals via the weekly update.
Brain (AI)	Extracts signals from notes, drafts tickets, never starts work, never edits existing tickets.

What this is not

• Not a bug-tracker for everything. Small inline cleanups inside an already-approved ticket don't need their own PS ticket. Use judgment.
• Not a status-reporting tool. Jira is the working board. The brain is the memory. Slack/standups are the conversation.
• Not optional for revenue-risk work. Anything that touches money requires a ticket, full stop.

Full spec

The canonical spec, including auth, the Atlassian Document Format payload, the helper script, and hard rules, lives in the brain at:

• pasarseken-ai-brain/workflow/jira-integration.md
• pasarseken-ai-brain/scripts/push-to-jira.sh
• pasarseken-ai-brain/scripts/extract-and-push.md

When that spec changes, this page is regenerated from the brain. Don't hand-edit it here.