Skip to content

[DONT MERGE] Test PR for commenting extension with diff - #2

Open
chienyuanchang wants to merge 1 commit into
mainfrom
test_pr_diff_doc
Open

[DONT MERGE] Test PR for commenting extension with diff#2
chienyuanchang wants to merge 1 commit into
mainfrom
test_pr_diff_doc

Conversation

@chienyuanchang

Copy link
Copy Markdown
Owner

No description provided.

This is the **overview paragraph**. It contains _emphasis_, `inline code`, and a [link to docs](https://example.com/docs). The goal is to have several paragraphs in a row so the text-matcher has to handle ordering.
This is the **overview paragraph**. It contains _emphasis_, `inline code`, and a [link to the docs](https://example.com/docs). The goal is to have several paragraphs in a row so the text-matcher has to handle ordering across small edits.

A second paragraph follows directly. Reviewers should be able to:

Copy link
Copy Markdown
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The numbered list below already covers item 1 ("comment on a whole paragraph"). Should we deduplicate, or is the prose intro worth keeping for context?

@@ -1,12 +1,15 @@
# Test Design Doc: Sample Feature Integration

> **Area**: testing

Copy link
Copy Markdown
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we tag this as area: testing-tools so the dashboard groups it correctly?

@chienyuanchang chienyuanchang May 20, 2026

Copy link
Copy Markdown
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch — I'll update the dashboard label list.(updated)

Comment thread test_md_files/sample-design-doc.md

---

## Architecture

Copy link
Copy Markdown
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add a brief one-line summary under this heading so readers skimming the outline know what's in here.

A-->>U: response
```

### Impact Analysis

Copy link
Copy Markdown
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this section explicitly call out backward compatibility for the schema changes?

Copy link
Copy Markdown
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

test


---

## Implementation Phases

Copy link
Copy Markdown
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Three phases feels right. Add expected duration per phase?


---

## Risks

Copy link
Copy Markdown
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add a row covering API stability assumptions — Service.handle relies on a 3rd-party SDK.

Comment on lines 125 to 129
**Goal**: Get the new service plumbing in place without changing observable behavior.

**Approach**: Add `Service` class with `accepts()` and `handle()` methods. Wire it into `Application.start` but only activate when an opt-in kwarg is set. Default path remains unchanged.

**Dependencies**: none.

Copy link
Copy Markdown
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we can comment on multiple lines

- [ ] `validate()` raises on malformed payloads
- [ ] `handle()` returns a valid `Response` for an accepted request

2. **Wire into the constructor**

Copy link
Copy Markdown
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

test first level

@@ -162,6 +184,8 @@

- [ ] Unit: each supported type routes to the expected backend

Copy link
Copy Markdown
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

checkbox

- Add `metrics.increment("service.backend.<name>")` per dispatch
- Add `metrics.increment("cache.hit")` / `metrics.increment("cache.miss")`
- Acceptance criteria:
- [ ] Counters fire on every relevant code path

Copy link
Copy Markdown
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

child

1. **Counters**
- File: `src/app/service.py`, `src/app/cache.py`
- Add `metrics.increment("service.backend.<name>")` per dispatch
- Add `metrics.increment("cache.hit")` / `metrics.increment("cache.miss")`

Copy link
Copy Markdown
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

first child

@@ -354,10 +442,13 @@

- [GitHub PR Review API](https://docs.github.com/en/rest/pulls/comments)

Copy link
Copy Markdown
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

one-level list


## Table of Contents

- [Overview](#overview)

Copy link
Copy Markdown
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

test

print(f"rejected: {e}")
```

### Shell

Copy link
Copy Markdown
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

here?


A second paragraph follows directly. Reviewers should be able to:

1. Comment on this entire paragraph from rich diff

Copy link
Copy Markdown
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

single list?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant