Skip to content
Limin Zheng

Tools & Development

Code review & bug fixing

Reproduce a bounded issue, then diagnose or fix it with test evidence.

Choose this when
Choose this to diagnose/fix a specific existing issue; choose Scoped feature development for feature requests.
Scope unit
One issue and reproducible environment
Possible delivery format
Diagnosis only: report and reproduction/blocking evidence; after approved repair: client-repo patch/PR and regression results

You send · You receive

What to send

  • Steps to reproduce, expected and actual behavior
  • Repository or authorized code package
  • Run commands, dependencies, branch and CI constraints

Start by describing the materials you already have; missing details can be added when we agree the scope. Before work begins, we will confirm the materials, permissions and working conditions needed for your specific task.

Two stages

Stage 1 · Diagnosis

A diagnosis order delivers a report: reproduction steps and results or blocking evidence, observed findings versus unverified hypotheses, repair feasibility, proposed scope and an optional repair quote. Unreproduced issues retain explicit uncertainty.

Possible outputs

  • Reproduction/blocking evidence, findings versus hypotheses, feasibility and proposed scope report, with optional repair quote

A diagnosis can be the complete order.

You decide whether to continue

Stage 2 · Approved implementation

After reproduction and repair scope are assessed in an authorized, limited-access client environment, only an approved repair includes a scoped patch/PR, executed regression evidence and remaining risks. The client controls merging; production release is not implicit.

Possible outputs

  • Scoped patch/PR in the client-controlled repo, executed commands and regression results

Scoped and quoted separately.

Both stagesBoth scopes document testing gaps, remaining uncertainty and applicable access handoff/cleanup

Third-party costsPaid dependencies, test/cloud resources, third-party APIs and model runs are not included in diagnostic or repair delivery fees and need separate agreement before use.

Key checkDiagnosis acceptance is the report, reproduction/blocking evidence, findings versus hypotheses, feasibility and proposed scope. Only separately approved repair requires a patch/PR and executed regressions; the client controls merging.

Verifiable acceptance · 3
  • Stage 1 · DiagnosisThe client receives a report distinguishing observed facts, unverified causes and feasibility; blocked reproduction includes evidence and next-step conditions
  • Stage 1 · DiagnosisDiagnosis acceptance does not require code changes; the client separately confirms repair scope and quote
  • Stage 2 · Approved implementationDeliver a scoped patch/PR, retest the original scenario and agreed regressions, document remaining risks; the client controls merging

Hypothetical brief & output structure

Illustration · hypothetical

Illustrative example — not a completed client order

The request

A form errors when a particular field is entered. Reproduce it before proposing a fix.

Sample artifacts

  • diagnosis.mdreproduction/blockers, findings/hypotheses, feasibility and scope
  • fix.patch / PRonly after separately approved repair
  • test-log.mddiagnostic reproduction log; executed regressions after approved repair

File names are illustrative

Other tasks of this kind

  • An existing report export sometimes produces empty files. First identify reproducible input conditions, then assess whether a fix is feasible.
Output structure / test path

Diagnosis: enter specified data → attempt reproduction → record failure or blockers → explain findings/hypotheses and feasibility; rerun original cases and regressions after approved repair.

Write a brief from this example →

Scope boundaries

Private repo needs limited access; diagnose reproducibility before fix quote; never publish/deploy without approval.

Not included by default

  • Guaranteed fix before reproducing the issue
  • Unauthorized merging or production deployment
  • Publishing private code or covering all unrelated defects

What affects the quote

Agree diagnosis report scope and price first; quote and implement repair only after client confirmation. Diagnosis guarantees neither a feasible repair nor overall code quality.

Actual project references

  • Roleward ↗

    Self-directed AI product

    Workflow and product practice, not evidence of market success or client delivery.

Self-directed work and published projects demonstrate relevant practice. They are not paid-client delivery records or guarantees for this task.

Start with a short note

Three answers are enough. I will reply with what else is needed and whether a diagnosis comes first. You get a quote before any work starts.

Prepare a brief →

Code review & bug fixing

Start with a short note

Three answers are enough. I will reply with what else is needed and whether a diagnosis comes first. You get a quote before any work starts.

What to send
  • Steps to reproduce, expected and actual behavior
  • Repository or authorized code package
  • Run commands, dependencies, branch and CI constraints
Illustration · hypothetical

Illustrative example — not a completed client order

The request

A form errors when a particular field is entered. Reproduce it before proposing a fix.

Example inputs

  • Authorized private repo and steps to reproduce
  • Test data, dependencies, branch and CI constraints

To start, it helps to mention

  • How is the bug triggered and what behavior is expected?
  • Can it be reproduced in a test environment, with logs or sample data?

Confirm before work begins: Authorized repo access, exact commit/environment and permitted tests

Public/de-identified information only. Private access requires separate authorization.

Preview the text
Services brief — B03 Code review & bug fixing

First contact does not require a complete specification. Unknown fields may be blank or marked unknown.

What do you want to end up with?


What do you already have?


When do you need it? Any budget range?

Select and copy the brief manually if scripting or clipboard access is unavailable.

Public email is a contact starting point. This site has no booking, payment or file-upload service. zhenglimin.design@gmail.com