[DONT MERGE] Test PR for commenting extension with diff - #2
[DONT MERGE] Test PR for commenting extension with diff#2chienyuanchang wants to merge 1 commit into
Conversation
| 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: |
There was a problem hiding this comment.
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 | |||
There was a problem hiding this comment.
Should we tag this as area: testing-tools so the dashboard groups it correctly?
There was a problem hiding this comment.
Good catch — I'll update the dashboard label list.(updated)
|
|
||
| --- | ||
|
|
||
| ## Architecture |
There was a problem hiding this comment.
Add a brief one-line summary under this heading so readers skimming the outline know what's in here.
| A-->>U: response | ||
| ``` | ||
|
|
||
| ### Impact Analysis |
There was a problem hiding this comment.
Should this section explicitly call out backward compatibility for the schema changes?
|
|
||
| --- | ||
|
|
||
| ## Implementation Phases |
There was a problem hiding this comment.
Three phases feels right. Add expected duration per phase?
|
|
||
| --- | ||
|
|
||
| ## Risks |
There was a problem hiding this comment.
Add a row covering API stability assumptions — Service.handle relies on a 3rd-party SDK.
| **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. |
There was a problem hiding this comment.
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** |
| @@ -162,6 +184,8 @@ | |||
|
|
|||
| - [ ] Unit: each supported type routes to the expected backend | |||
| - 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 |
| 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")` |
| @@ -354,10 +442,13 @@ | |||
|
|
|||
| - [GitHub PR Review API](https://docs.github.com/en/rest/pulls/comments) | |||
|
|
||
| ## Table of Contents | ||
|
|
||
| - [Overview](#overview) |
| print(f"rejected: {e}") | ||
| ``` | ||
|
|
||
| ### Shell |
|
|
||
| A second paragraph follows directly. Reviewers should be able to: | ||
|
|
||
| 1. Comment on this entire paragraph from rich diff |
No description provided.