Request code changes from Telegram and review the GitLab merge request

Why use this

1. A developer requesting a small change while away from a workstation still needs to know which files changed and what checks were performed. A chat request can be ambiguous, especially when several projects or branches share similar names.

2. This job could translate a scoped request into a reviewable merge-request proposal while preserving branch and deployment boundaries. A clear change/check summary lets the human reviewer decide whether the implementation matches intent rather than relying on a conversational completion claim.

Why an agent / simpler alternative

Useful judgment

Resolve request scope, identify relevant repository areas and explain check coverage and unresolved risks.

Simpler alternative

Use a normal issue or edit locally when the change is straightforward and workstation access is available.

Unsuitable when

Project identity is unclear or the workflow would bypass review, write to the main branch or deploy.

Proposed inputs

1. Name

   Change request

   Owner

   Repository owner

   Minimum scope

   Exact project, intended behavior and exclusions

   Quality check

   Clarify ambiguous wording before editing

2. Name

   Repository context

   Owner

   Authorized maintainer

   Minimum scope

   Relevant files, branch policy and check definitions

   Quality check

   Exclude secrets and identify protected paths

Access and setup — proposed or unknown

Proposed minimum

1. Begin with a fictional repository/request review; no Telegram connection, repository writes, checks or merge request creation.

Compatibility unknowns

1. Current chat routing, isolated runtime, repository permissions and tool compatibility are unknown.

External actions requiring approval

1. Branch creation, code changes, external merge requests and access grants require scoped authorization; human review/merge remains explicit.

Expected deliverable and review checks

Proposed artifact

Proposed change plan with file scope, acceptance checks, branch boundary and reviewer questions.

Critical checks

1. Match request to the correct project; preserve protected branches; distinguish proposed checks from executed results; exclude deployment.

Missing output evidence

This overlay adds no new output inspection, execution or validation; consult the referenced canonical source outcome limits.

Failure signals and proposed responses

1. Signal

   A chat topic maps to the wrong repository

   Why it matters

   A valid change lands in the wrong project

   Proposed response

   Verify project identity before any mutation.

2. Signal

   A narrow test is described as complete verification

   Why it matters

   The reviewer receives false confidence

   Proposed response

   List exact coverage and remaining checks.

Effort and cost — unknown

Setup work

1. Define project mapping and review constraints.

Ongoing review

1. Human reviews the diff and authorized check evidence before merging.

Unknowns

1. Environment access, test coverage, dependencies and execution costs are unknown.

First check — proposed, unexecuted

Status

proposed_unexecuted

Synthetic fixture

Invent two repositories with similar names and a request to change one page; draft scope questions and a check plan only.

Acceptance checks

1. Resolve project ambiguity; bound files; claim no tests ran; create no branch or merge request.

Stop conditions

1. Stop if project authorization or protected-branch boundaries are unresolved.

Limits

1. A merge-request plan cannot establish code correctness, deployment readiness or permission to merge.