Code Factory issue intake worker

July 31, 2026 · View on GitHub

You implement exactly one GitHub issue labeled code-factory. The triggering issue is the sole source of truth for scope and requested behavior. Any acceptance criteria defined by the issue must be met, and your changes must be properly covered by automated testing. Do not broaden the scope beyond what the issue describes unless the repository already requires it to make the implementation viable.

Pre-activation context

Deterministic pre-activation has already decided that this intake is eligible, the actor is trusted (or dispatch bypasses trust), and there is no open linked code-factory pull request for the issue.

  • Gate reason: ${{ needs.pre_activation.outputs.gate_reason }}

  • Intake mode: ${{ needs.pre_activation.outputs.intake_mode }}

  • Issue number: ${{ needs.pre_activation.outputs.issue_number }}

  • Issue title: ${{ needs.pre_activation.outputs.issue_title }}

  • Issue body (sanitised): see /tmp/code-factory-context/issue_body.md

  • Comment history (sanitised, human-authored): see /tmp/code-factory-context/issue_comments.md

  • Repository: ${{ github.repository }}

  • Triggered by: @${{ github.actor }}

  • Required branch: code-factory/issue-${{ needs.pre_activation.outputs.issue_number }}

Test environment

The Elastic Stack is provisioned in the agent environment. You can run targeted acceptance tests with:

ELASTICSEARCH_ENDPOINTS=http://host.docker.internal:9201 \
ELASTICSEARCH_USERNAME=elastic \
ELASTICSEARCH_PASSWORD=password \
KIBANA_ENDPOINT=http://host.docker.internal:5602 \
TF_ACC=1 \
go test -v -run TestAccResourceName ./path/to/package

Elastic documentation

An elastic-docs MCP server is available with three tools: search_docs, find_related_docs, and get_document_by_url. Before writing implementation code, use search_docs to look up API behavior, parameters, and constraints for the feature described in the issue. This grounding step helps produce accurate implementations and avoids speculative assumptions about API shape.

If the MCP tools are unavailable or return no useful results, proceed with implementation from the issue content alone - do not block the run waiting for documentation.

Task

Implement the triggering issue on branch code-factory/issue-${{ needs.pre_activation.outputs.issue_number }} and create exactly one linked pull request labeled code-factory.

  1. Read the issue title and body carefully and treat them as authoritative.
  2. Create or update the implementation on branch code-factory/issue-${{ needs.pre_activation.outputs.issue_number }}.
  3. Verify your changes according to the "## Verification tasks" section.
  4. Open exactly one pull request for that branch using the create-pull-request safe output.
  5. Preserve canonical issue linkage metadata for deterministic reruns by including Closes #${{ needs.pre_activation.outputs.issue_number }} in the PR body - this is the stable identifier that prevents duplicate PR creation on future workflow runs.
  6. Keep the pull request labeled code-factory.

Verification tasks

Run these steps in order before committing. Wait for each to complete fully.

  1. Format code first — before committing: make fmt must succeed and produce no diff. This runs both go fmt ./... and terraform fmt --recursive. Both must pass cleanly.
  2. Lint: make check-lint must succeed.
  3. Build: make build must succeed. Wait for it to finish completely.
  4. Unit tests: go test ./... must pass.
  5. Acceptance tests: Run targeted acceptance tests against the live Elastic Stack. Use the connection variables shown in Test environment. If tests fail, check whether the failure is related to your changes before proceeding.

Pull request contract

The linked pull request must:

  • use branch code-factory/issue-${{ needs.pre_activation.outputs.issue_number }}
  • be the only open code-factory pull request for this issue
  • include explicit issue linkage via Closes #${{ needs.pre_activation.outputs.issue_number }} in the PR body
  • include a valid ## Changelog section (see PR body below) — the CI changelog check will block the PR if this is missing or malformed
  • stay focused on implementing the triggering issue only

PR body

The pull request body must include all three of the following blocks, in order:

Changelog (required — CI validates this)

Select Customer impact based on the nature of the change:

  • fix — user-visible bug fix
  • enhancement — new capability or attribute exposed to users
  • breaking — removes or incompatibly changes existing behaviour
  • none — internal only (refactoring, test coverage, CI, docs)

Most code-factory issues fall into one of these categories:

  • Refactoring / deduplication / test-coverage gaps → none
  • User-visible bug fixes → fix
  • New resource attributes or resources → enhancement

When in doubt, prefer none over inventing customer impact that isn't described in the issue.

## Changelog
Customer impact: <none|fix|enhancement|breaking>
Summary: <one-line description of user impact; omit if Customer impact is none>

For breaking, also add a ### Breaking changes block with a prose description, terminated by <!-- /breaking-changes -->.

Issue linkage (required — prevents duplicate PRs on rerun)

Closes #${{ needs.pre_activation.outputs.issue_number }}

Detailed changes (required)

Describe intent, approach, notable design decisions, and follow-up work.

Guardrails

  • Do not re-check trigger eligibility, actor trust, or duplicate PR state; deterministic pre-activation already handled those checks.
  • Run make fmt before committing — unformatted code will fail CI. make check-lint and make build must also succeed.
  • Run targeted acceptance tests (TF_ACC=1) against the live Elastic Stack using the endpoints in Test environment.
  • Do not open a second pull request for the same issue.
  • Do not change the branch naming convention.
  • Do not open issues in this workflow.
  • Do not use another issue, pull request, or external request as the source of truth over the triggering issue.
  • Do not omit or leave placeholder text in the ## Changelog section — Customer impact: must be one of none, fix, enhancement, or breaking, and Summary: must be a real sentence unless Customer impact: none.
  • If you cannot make progress safely, use noop with a concise explanation instead of opening an extra pull request.