Approval-Gated Pulsar Code Change

Pulsar Code separates preparing a repository change from publishing it. A task is bound to an exact repository context, branch, and base revision. The coding run occurs in an isolated workspace where the agent can inspect files, prepare a patch, and run permitted checks. Reviewers see evidence before any repository publication. A branch push requires its own exact, single-use approval. Creating a draft pull request requires a second exact, single-use approval.

That separation is the control. The system can produce useful work without granting ambient permission to modify the remote repository. Approval is not a general unlock, and one approval cannot authorize both publication steps. The workflow does not merge a pull request, write directly to the default branch, or make a reusable permission token available to later tasks.

Control objective

The objective is to make the proposed change inspectable before external effect. A reviewer should be able to answer: Which repository and base revision were used? What goal was given? Which files changed? What checks ran? What failed or remained unverified? Which exact branch action is requested? Has that action changed since approval? What durable receipt proves the result?

• Bounded input: repository, branch, exact base revision, task goal, model, policy, and engine context are recorded for the run.
• Isolated preparation: the coding process works in a task-specific environment rather than directly in a shared checkout or default branch.
• Reviewable evidence: file evidence, diff, checks, limitations, and task status are available before publication.
• Exact approval: the approved action is cryptographically bound to its material parameters and can be consumed only once.
• Separate effects: branch push and draft pull-request creation are different actions with different approvals and repository permissions.
• Durable receipt: the result of the publication attempt is recorded so later review does not depend on a transient worker message.

Approval sequence

Diagram transcript

1. 1. The task records the repository, source branch, exact base revision, model, policy, engine context, and requested goal.
2. 2. Pulsar Code creates an isolated workspace and confirms that the expected base revision is present before work begins.
3. 3. The agent inspects allowed files, prepares changes, and runs permitted checks without remote publication authority.
4. 4. Pulsar records the patch, changed-file evidence, check outcomes, limitations, and current task state for review.
5. 5. A reviewer grants an exact single-use approval for the named branch-push action and its bound parameters.
6. 6. Pulsar Code creates the approved commit and pushes the approved non-default branch, then records a durable receipt.
7. 7. A reviewer separately grants an exact single-use approval for creating the specified draft pull request.
8. 8. Pulsar Code creates the draft pull request and records the resulting repository reference and checks; merge remains outside the workflow.

Bind the task before execution

A repository name alone is not a stable work target. Pulsar Code binds the run to the selected repository, source branch, and exact base revision so the reviewer can reason about what the agent saw. Model, policy, and engine context are also part of the task record. If the remote branch moves later, the original run does not silently become evidence for a different base.

The requested goal should be concrete enough to review: identify the behavior to change, the relevant constraints, and the expected checks. Avoid instructions that grant a vague mandate across the repository. A bounded goal narrows file discovery, improves evidence, and helps a reviewer detect unrelated changes.

Prepare changes in isolation

The task-specific workspace keeps preparation separate from a developer’s active checkout and from the remote default branch. The agent can read the repository context allowed by policy, edit the isolated copy, and run permitted local checks. Isolation limits accidental cross-task state, but it is not a complete security boundary by itself. Repository contents, tools, model behavior, container policy, credentials, and network access still require review.

Preparation does not require approval for every local edit. That would make iteration impractical and would confuse workspace mutation with external effect. The high-risk boundary is publication to the repository service. Reviewers should still inspect the entire patch and check evidence before approving that effect.

Review evidence, not only the summary

A concise task summary is useful for orientation, but it cannot replace file and diff evidence. Review changed paths, additions and deletions, test commands, command outcomes, and any skipped checks. Confirm that generated files, credentials, environment artifacts, and unrelated formatting did not enter the patch. When a check cannot run, the limitation should remain visible rather than being converted into a success statement.

Evidence	Reviewer question	Blocking example
Repository and base binding	Is this the intended repository, branch, and exact starting revision?	Base mismatch or branch changed without a new run.
Changed-file set	Does every changed path support the approved goal?	Unrelated configuration, credentials, build output, or broad mechanical churn.
Diff	Is the behavior coherent, scoped, and free of hidden external effects?	Direct publication logic, policy bypass, destructive operation, or unexpected dependency.
Checks	Did the relevant tests, lint, or build run, and what exactly passed?	Missing high-risk test or a failed check represented as successful.
Limitations	What remains unverified and who accepts that risk?	Production-readiness claim based only on static inspection.

Approve an exact branch push

Branch publication is a distinct action. The approval is bound to the material push parameters and is single-use. If the branch target, repository, prepared state, or other bound action data changes, the prior approval is not a general permission to continue. A reviewer must inspect the new action and issue a new approval.

The push targets an approved non-default branch. Pulsar Code creates the commit and attempts the exact publication, then stores the outcome as a durable receipt. A failure should remain a failed or uncertain publication state until repository state is reconciled. Repeating a push should not be treated as harmless merely because the desired content appears similar.

Approve a draft pull request separately

A successful branch push does not authorize creating a pull request. The draft pull-request action has a separate exact approval because it creates another repository-visible object, chooses source and target branches, and can trigger checks or notifications. The GitHub App permissions used for branch publication and pull-request creation are also distinct.

The result is a draft pull request for human review. It is not an approval to merge, mark ready, modify branch protection, or write to the default branch. Repository owners retain their normal review, required-check, and merge controls.

Failure modes and safe responses

Failure	Control interpretation	Safe response
Base revision no longer matches	The prepared evidence belongs to an earlier repository state.	Stop publication, refresh intentionally, rerun checks, and request new approval.
Checks fail or cannot run	The task has a visible verification limitation.	Fix in isolation or present the limitation explicitly; do not label the task verified.
Approval parameters changed	The action no longer matches the approved effect.	Invalidate the path and require a new exact approval.
Branch push outcome is uncertain	Retry could create a duplicate or hide the actual remote state.	Reconcile durable receipt and remote branch state before another attempt.
Draft PR creation fails	The branch may still be published, but the second effect did not complete.	Preserve the push receipt, fix the PR-specific issue, and obtain an exact approval for the new action if parameters change.
Unexpected sensitive file appears	The patch may expose credentials or private data.	Block publication, remove the file in isolation, rotate exposed credentials if needed, and restart review.

Reviewer checklist

• Confirm the repository, source branch, exact base revision, goal, model, and policy match the intended task.
• Inspect every changed file and the complete diff, not only the agent summary.
• Verify that relevant checks ran and that failures or skipped checks remain visible.
• Scan for credentials, private infrastructure, personal data, generated artifacts, and unrelated changes.
• Confirm the requested publication targets a non-default branch and matches the prepared evidence exactly.
• Grant the branch-push approval only for that action, then inspect its durable receipt and remote state.
• Review the draft pull-request parameters separately and grant a second exact approval only when appropriate.
• Leave merge, branch protection, required checks, and final release decisions to the repository’s normal governance.

Common Pulsar Code questions

Does Pulsar Code need approval before editing its isolated workspace?

No. The agent can prepare and test a change in the isolated task workspace. Approval is required for the exact external publication actions described here.

Can one approval push the branch and create the pull request?

No. Branch push and draft pull-request creation are separate effects with separate exact, single-use approvals.

Can Pulsar Code merge the pull request?

The reviewed workflow does not grant merge authority. It creates a draft pull request for the repository’s normal human and automated review process.

Can an approval be reused after the patch changes?

No. Approval is bound to the exact action data and consumed once. A changed action requires new evidence and a new approval.

Does this field note prove production readiness?

No. It documents the reviewed control path and its limits. Each organization must qualify repository permissions, isolation, models, policy, checks, incident handling, and release governance in its own environment.