Skip to main content

Submit the work

Run the final local checks, publish the work as a branch, and open a pull request that another engineer can understand without reconstructing the ticket or implementation.

Prerequisites​

  • Local execution is complete, including automated tests for the changed behavior.
  • Access to publish the source-code branch and, when required, a Builder branch.

Complete the pull request checklist​

  • Use the appropriate agents to review the code, following the LogicBee AI coding guide, and resolve their findings.
  • Update context.md with durable context introduced or changed by the work.
  • Confirm the automated tests added during execution are included.
  • Complete any Builder work identified by the ticket and publish it as a branch when it must be tested with the source-code branch.
  • Run pnpm diagnose:errors successfully.
  • Run pnpm prod successfully.
  • Confirm the ticket, plan, documentation, and remaining limitations are current.
  • Publish the source-code branch.
  • Create the pull request, link it to the ticket, and leave it as a draft until branch testing passes.

If the repository defines different validation commands, run its documented equivalents and record what was run in the pull request. Do not skip a check silently: mark it not applicable and explain why.

Builder​

Every pull request must contain a Builder section. State whether Builder changes are needed. When they are, list the exact work so a reviewer or tester can reproduce the complete change.

## Builder

Required: Yes | No
Branch:
Changes:
Publish or import order:
Verification:

Include Builder pages, workflows, data models, permissions, configuration, or other artifacts that must change. Name the Builder branch and whether it must be published before or after the source-code branch. If no Builder work is needed, write Required: No and omit the remaining fields.

Do not rely on unpublished personal Builder state or an unlinked description in chat. The pull request must identify the Builder branch used for testing.

Prepare the pull request​

The pull request should state:

  • the problem and intended outcome;
  • the source-code and Builder changes made;
  • how the work was verified locally and what remains for branch and human testing;
  • any migration, rollout, rollback, or operational considerations; and
  • known limitations or follow-up tickets.

Keep the pull request focused on the ticket. Split unrelated changes before requesting review.

Expected result​

The source-code branch and any required Builder branch are published. The pull request is open, linked to the ticket, and contains enough context for branch testing.

If a final check fails​

Return to execution, correct it, and repeat the checklist. Do not open a pull request on a branch you know is invalid.

Next: Test the published work.