Automation: pilot owner-triggered implementation for accepted Issues

Goal

Add a small, owner-triggered implementation pilot for work that has already been explicitly accepted. This is repository-maintenance automation, not a new agent framework in the TypeChat library.

This follows #503. The owner has requested an agent-prepared proposal for review; opening this issue and requesting a draft do not accept the work or start a coding run.

Proposed scope

Add a separate, owner-only /typechat build workflow for accepted Issues in the first pilot. Each command must identify the exact acceptance record and its hash; provide a copyable command rather than requiring hand-calculated identifiers.
Verify the original owner acceptance, the unchanged public acceptance record, the current approved project policy, and a fresh owner build command. Do not rely on an expired draft artifact as the only surviving scope record.
Freeze the accepted terms and source revision. Stop on unclear or changed scope, withdrawn authorization, or an existing implementation PR rather than duplicating another contributor's work.
Let the coding agent edit and test an isolated checkout without repository-write credentials. Keep privileged GitHub operations in trusted preflight/publisher jobs, and never run generated code or tests with the App's credentials.
Use the documented proposed 1,000-credit main implementation budget, with threat detection budgeted separately. Keep finite time/turn limits and explicit usage reporting. Budget activation requires the normal owner-reviewed workflow change; this proposal/draft spends no implementation allowance.
After successful completion, relevant deterministic builds/tests, full-patch threat detection, and final provenance/freshness checks, publish one owned branch and one PR for human review. Do not approve or merge the PR automatically.

Existing PR-writer identity

Reuse typeagent-bot, not a new App or personal access token. The repository already has the DEPENDABOT_APP_ID variable and DEPENDABOT_APP_PRIVATE_KEY secret used by the existing workflow. Its token-generation and authentication steps succeeded in run 41291679616.

The new workflow should request short-lived tokens limited to TypeChat and the necessary repository-content/PR permissions. It must not inherit the App's unrelated vulnerability-alert permission, expose its key/token to the coding agent, rename or rotate existing credentials, or change the existing Dependabot workflow. Validate App identity, installation, and requested permissions before inference, and revalidate before publishing.

Keep the repository's default GITHUB_TOKEN permissions read-only and its PR-creation/approval setting unchanged. App-authored PRs can trigger normal CI; verify actual CI and Copilot review behavior in the live pilot rather than assuming it.

Proposed acceptance criteria

Offline tests reject unauthorized users/bots, PR-comment triggers, untrusted refs, missing/edited acceptance records, wrong hashes, withdrawn commands, and policy/scope changes before model execution or writes.
The model and untrusted build/test processes cannot access repository-write credentials; only trusted jobs mint/use the scoped App token.
A verified successful model completion, required test results, and a successful full-patch scan are mandatory before publication. Missing, incomplete, failed, or mismatched evidence must not become a successful result.
A rerun of an already handled command returns its existing result without another coding run or PR. Uncertain branch/PR writes block blind retries; no automatic retry-spending or force-pushing over other work.
The PR links the accepted scope and reports the pinned base, exact patch provenance, checks actually run, limitations, and existing contributor credit. CI, Copilot review, and human review remain distinct steps.
Deterministic tests cover both the happy path and failure/retry cases. Workflow compilation must be strict and reproducible, and operator documentation must explain activation, budgets, recovery, and a first live pilot on genuinely agreed work.

Non-goals and boundaries

No automatic acceptance, scope expansion, budget override, PR approval/merge, issue closure, or release.
No Discussion-based implementation or inline implementation notes in the first pilot; Automation: support implementation notes with work acceptance #502 remains deferred. Existing discussion/reply/acceptance behavior is preserved.
The future coding agent may not modify its own automation, policy, permissions, credentials, or branch protections. Maintainers add/change those controls through normal reviewed PRs.
Do not change App settings, repository permissions, or credentials as part of preparing this proposal. Missing provisioning is an explicit blocker, not a reason to bypass controls.
Preserve the existing library APIs, supported integrations, and contributor work. This milestone adds automation, not unrelated library changes.

Approval status

Proposal only. Request a fresh /typechat draft, review its exact work-acceptance preview, and obtain an explicit owner decision before implementation. No live coding run, permission change, credential change, or merge is authorized by this issue or the draft request.

/typechat draft

Maintainer confirmation of the proposed boundaries

I confirm the intended reuse of the existing typeagent-bot for TypeChat. The new implementation workflow must request short-lived tokens limited to TypeChat and the necessary repository-content and pull-request permissions. Do not rotate keys, remove permissions used by existing workflows, or broaden the repository's default GITHUB_TOKEN settings.

The authorization/publication boundary reviewed in #503 and the requirements in this issue are confirmed: App credentials and privileged publishing belong only in trusted jobs, separate from the coding agent and its test processes.

These are requirements for the new implementation. Effective token scoping and credential isolation must still be demonstrated by its tests and preflight checks before live execution; this confirmation does not claim that unwritten code already exists or has been verified.

This confirms the intended boundaries, not acceptance of an exact generated proposal. It does not activate an implementation budget, start a coding run, change permissions, or approve merging. A fresh proposal still requires owner review before an acceptance command is posted.

/typechat draft

/typechat accept 13096192537:46a63894d52a3dff01c160f42bf9a1cf5ca760bd1bc3352eff05c1f58d768f7e

Accepted work

Approved by the project owner, robgruen, for issue #504.

Goal

Let the owner separately authorize one bounded implementation run for explicitly accepted Issue work and receive a pull request tied to that agreement for human review, without exposing repository-write credentials to the coding agent or generated code.

Scope

Add a separate owner-only Issue build command that identifies the exact acceptance record and hash, with a copyable command and validation of the durable public record.
Freeze accepted terms and the source revision, verify current policy and contribution references, and require fresh authorization before inference and publication.
Add isolated coding and test execution plus trusted preflight and publishing jobs that reuse typeagent-bot with short-lived TypeChat-scoped tokens limited to necessary content and PR permissions.
Configure the proposed 1,000-credit main implementation budget, separate threat-detection spending, finite execution limits, and usage reporting through a normal owner-reviewed workflow change.
Gate one owned branch and one human-review PR on verified completion, relevant deterministic checks, a full-patch scan, and final authorization and patch-origin checks, with duplicate and uncertain-write protection.
Add offline success and failure tests, strict reproducible workflow compilation, and operator documentation for activation, budgets, recovery, and separately authorized live verification.

Non-goals

No automatic work acceptance, scope expansion, budget override, retry spending, issue closure, release, PR approval, or merge.
No Discussion implementation runs or inline implementation notes; deferred Issue 502 remains unchanged.
No new App or personal access token, credential rotation, App setting changes, broader repository permissions, or changes to the existing Dependabot workflow.
No repository-write credentials in the coding agent or generated build and test processes, and no inheritance of the App's unrelated vulnerability-alert permission.
No future coding-agent changes to its own automation, policy, permissions, credentials, or branch protections. Maintainers change those controls through normal owner-reviewed PRs.
No TypeChat library feature or API changes, weakening of validation, deprecation of supported integrations, replacement of contributor work, or general-purpose agent platform.

Acceptance criteria

Offline authorization tests reject unauthorized users and bots, PR-comment triggers, untrusted refs, missing or edited acceptance records, wrong hashes, withdrawn commands, and changed policy or scope before model execution or repository writes. An authorized Issue command binds the exact record and hash and has a generated copyable form.
A successful preflight freezes accepted terms and the source revision, validates the durable public record independently of draft-artifact expiry, and checks for existing implementation work. An existing implementation PR or unclear authorization stops the run instead of generating a competing patch.
Preflight and publisher checks validate the intended App identity, installation, TypeChat-only repository selection, and requested content and PR permissions. Offline isolation tests demonstrate that the coding agent and generated build and test processes cannot access the App key, App token, or any repository-write credential. Missing or excessive permissions block execution or publication.
The reviewed workflow configuration enforces a 1,000-credit main implementation limit, a separate explicit threat-detection budget, finite time and turn limits, and usage reporting. Budget exhaustion or incomplete execution cannot publish a PR or trigger automatic retry spending. Preparing or accepting a proposal does not activate this allowance.
Publication requires successful model completion, passing relevant deterministic builds and tests, a successful scan of the entire exact patch, and final checks tying the result to the accepted scope and fixed source revision. Missing, failed, incomplete, stale, or mismatched evidence blocks branch and PR publication.
Deterministic retry tests show that an already handled command returns its recorded result without another model run, branch, or PR. Uncertain or partial publication blocks blind retries and preserves other contributors' branches and changes without force-pushing.
A successful authorized run publishes exactly one owned branch and one human-review PR. Its description links the accepted scope and reports the fixed base revision, exact patch origin, checks actually run, limitations, usage, and existing contributor credit. Publication revalidates authorization, App access, policy, source freshness, and competing contributions.
The pilot rejects generated changes to its own automation, policy, permissions, credentials, or branch protections. The existing Dependabot workflow, default token permissions, PR-creation and approval setting, library APIs, supported integrations, and draft, reply, and acceptance behavior remain unchanged. No Discussion build or inline-note implementation is added.
Offline tests cover successful execution and authorization, isolation, budget, completion-evidence, scan, publication, and retry failures. Strict compilation succeeds reproducibly without generated-file drift. Operator documentation explains activation, separate budgets, usage, recovery from uncertain writes, and the separately authorized first live pilot.
A separately owner-authorized live pilot on genuinely agreed work records whether normal continuous integration checks and Copilot review actually ran. Neither is reported as successful without evidence. Automated checks, Copilot review, human approval, and merging remain distinct, with no automatic approval, merge, issue closure, or release.

Existing contributions

#503 at c9bb9da
#339 at 1646f96

Proposal run | Approved scope policy

This accepts the scope above. It does not start or authorize an automated implementation run, increase any budget, or approve merging. Material scope changes require a new proposal and owner decision.

/typechat draft

TypeChat: Draft prepared; owner or maintainer input is still needed before work acceptance.

Owner request | Run and preview

Operational receipt only. This comment does not publish draft text, accept work, authorize implementation, or approve merging.

/typechat draft receipt-smoke-invalid

TypeChat: The request was rejected. Post only /typechat draft or /typechat reply in a new comment.

Owner request | Run and preview

Operational receipt only. This comment does not publish draft text, accept work, authorize implementation, or approve merging.

Navigation Menu

Repository navigation

Automation: pilot owner-triggered implementation for accepted Issues #504

Goal

Proposed scope

Existing PR-writer identity

Proposed acceptance criteria

Non-goals and boundaries

Approval status

Maintainer confirmation of the proposed boundaries

Accepted work

Goal

Scope

Non-goals

Acceptance criteria

Existing contributions

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Automation: pilot owner-triggered implementation for accepted Issues #504

Description

Goal

Proposed scope

Existing PR-writer identity

Proposed acceptance criteria

Non-goals and boundaries

Approval status

Activity

robgruen commented on Nov 1, 2026

robgruen commented on Nov 1, 2026

Maintainer confirmation of the proposed boundaries

robgruen commented on Nov 1, 2026

robgruen commented on Nov 1, 2026

github-actions commented on Nov 1, 2026

Accepted work

Goal

Scope

Non-goals

Acceptance criteria

Existing contributions

robgruen commented on Nov 2, 2026

github-actions commented on Nov 2, 2026

robgruen commented on Nov 2, 2026

github-actions commented on Nov 2, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions