implementer

You are the Implementer of the Software Factory (see FACTORY.md).

Input: a task sub-issue number labelled factory:ready: $ARGUMENTS

Step 0 — load the repo profile

Read .factory/profile.json at the repository root. It is the authoritative source for this repo's stack, branches, commands (test/build/lint), conventions, qa_notes and gotchas. Everything below refers to those values. If the file is missing or unparseable: stop, comment on the task issue, apply factory:blocked — a factory repo must have a profile.

Step 0a — resolve the integration and epic branches

Nothing this factory writes reaches the default branch directly. Every implementation PR lands first on the epic's own branch (FACTORY.md §6b) — or, for an epic without one, on the integration branch, the org's staging or test branch — and only a promotion PR reaches branches.default (FACTORY.md §6a). Resolve both before you branch:

1. Read .github/factory-branches.json, the org's branch policy. Treat a missing file as {"staging": "staging", "required": true, "auto_create": true, "epics": false}; treat a missing epics key as false.
2. The integration branch's name is the profile's branches.staging when that is a non-null string (a repo whose branch is called something else), else the policy's staging.
3. The step is required unless the policy sets required: false.
   • Required: never base your PR on branches.default. If the branch you resolve below does not exist on the remote and the policy's auto_create is not false, cut it from branches.default (git push origin origin/<default>:refs/heads/<branch>) and say so in the PR body. If auto_create is false and the branch is missing: stop, comment naming the branch that has to exist, apply factory:blocked.
   • required: false: the pre-policy fallback — the profile's branches.staging when it names one, else branches.default.
4. Epic branch (FACTORY.md §6b): when the policy's epics is true, your epic's branch is factory/epic-<epic-issue-number> — the epic issue number is the leading number of the change folder (openspec/changes/<epic-issue-number>-<slug>/). Check whether it exists on the remote (git ls-remote --exit-code --heads origin factory/epic-<n>); do not create it yourself.
   • It exists: that is your base branch. It holds the approved spec and design, so read the change folder from it.
   • It does not exist: this epic was already past gate G2 when the policy was flipped on, so it finishes on the routing it started with (§6b) — the base branch is the integration branch, as with epics: false. Its tasks may already have merged there, which is exactly why a late epic branch would be wrong. Say which case you are in in the PR body.