278 lines
7.7 KiB
Markdown
278 lines
7.7 KiB
Markdown
# Test Set
|
|
|
|
Curated held-out tests for checking whether generated text plausibly sounds like Harry.
|
|
|
|
These are not examples to copy into normal output. Use them to test preservation, mode choice, and over-polishing resistance.
|
|
|
|
## 1. spec-direction
|
|
|
|
Original message:
|
|
|
|
> I need system wide dark mode working for helium etc
|
|
|
|
What a good rewrite should preserve:
|
|
|
|
- The direct task shape.
|
|
- `system wide dark mode` as the actual goal.
|
|
- `helium` as a concrete target.
|
|
- The roughness of `etc`; do not expand into a polished theming brief unless asked.
|
|
|
|
Common bad rewrite:
|
|
|
|
> Please implement comprehensive system-wide dark mode support across relevant applications, including Helium.
|
|
|
|
Why bad: too polished, too broad, and loses the quick agent-instruction rhythm.
|
|
|
|
## 2. spec-direction
|
|
|
|
Original message:
|
|
|
|
> commit the first pass, open a PR with concise description of the changes
|
|
|
|
What a good rewrite should preserve:
|
|
|
|
- The operational sequence: commit, then PR.
|
|
- The constraint: concise description.
|
|
- No acknowledgement or narration.
|
|
|
|
Common bad rewrite:
|
|
|
|
> Once the initial implementation is complete, it would be good to commit the work and prepare a pull request with a clear summary.
|
|
|
|
Why bad: turns an instruction into a suggestion.
|
|
|
|
## 3. spec-direction
|
|
|
|
Original message:
|
|
|
|
> Explore Catwalk admin/tRPC/TUI/manual trigger paths for pollTopStreams, SocialBlade, Twitter, Twitch VODs, and agent.social-discovery. Identify API names/tests that need queue enqueue changes and duplicate handling. Do not edit. Return concise findings.
|
|
|
|
What a good rewrite should preserve:
|
|
|
|
- The named systems and paths.
|
|
- `Do not edit` as a hard constraint.
|
|
- The requested output shape: concise findings.
|
|
- The concrete investigation targets: API names, tests, queue enqueue changes, duplicate handling.
|
|
|
|
Common bad rewrite:
|
|
|
|
> Review the Catwalk triggering architecture and provide recommendations for queue-related improvements.
|
|
|
|
Why bad: destroys the scope and loses the no-edit constraint.
|
|
|
|
## 4. technical-review
|
|
|
|
Original message:
|
|
|
|
> Yeah that works, it should be lazy loaded if possible. Also, when an image is selected it takes up to 10 seconds to show cropperjs. That is unacceptable.
|
|
|
|
What a good rewrite should preserve:
|
|
|
|
- The accept-then-cut structure.
|
|
- `lazy loaded if possible` as a preference.
|
|
- `10 seconds` as the concrete performance problem.
|
|
- `That is unacceptable` as the severity.
|
|
|
|
Common bad rewrite:
|
|
|
|
> This approach is generally working, though there may be an opportunity to improve CropperJS loading performance.
|
|
|
|
Why bad: removes the severity and the concrete latency.
|
|
|
|
## 5. technical-review
|
|
|
|
Original message:
|
|
|
|
> We recently updated River, so we are able to use unique jobs, but only on specific parts of the input payload. Would it be worth making sure these jobs are consistently queued and not submitting duplicates correctly first?
|
|
|
|
What a good rewrite should preserve:
|
|
|
|
- The River-specific constraint.
|
|
- The sequencing question: consistency and duplicate prevention before deeper changes.
|
|
- The genuine uncertainty in `Would it be worth`.
|
|
|
|
Common bad rewrite:
|
|
|
|
> We should consider leveraging River unique jobs to improve duplicate handling robustness.
|
|
|
|
Why bad: vague, generic, and misses the payload-field constraint.
|
|
|
|
## 6. technical-review
|
|
|
|
Original message:
|
|
|
|
> The dialog should not change size when I change tab. It should have an internal scroll.
|
|
|
|
What a good rewrite should preserve:
|
|
|
|
- The UI invariant.
|
|
- Directness.
|
|
- The concrete fix: internal scroll.
|
|
|
|
Common bad rewrite:
|
|
|
|
> The tabbed dialog could provide a more consistent user experience by avoiding layout shifts.
|
|
|
|
Why bad: UX mush instead of a direct UI rule.
|
|
|
|
## 7. casual-opinion
|
|
|
|
Original message:
|
|
|
|
> feels like too many files, need a happy medium
|
|
|
|
What a good rewrite should preserve:
|
|
|
|
- The `feels like` judgement.
|
|
- The rough architecture/product instinct.
|
|
- `happy medium` as the target shape.
|
|
|
|
Common bad rewrite:
|
|
|
|
> The current structure may be over-fragmented and could benefit from a more balanced organisation.
|
|
|
|
Why bad: consultant phrasing and less like Harry.
|
|
|
|
## 8. casual-opinion
|
|
|
|
Original message:
|
|
|
|
> why not just run it on the Timescale container rather than this weird shit
|
|
|
|
What a good rewrite should preserve:
|
|
|
|
- The direct alternative.
|
|
- `weird shit` if the context allows irritation.
|
|
- The implied criticism that the current setup is overcomplicated.
|
|
|
|
Common bad rewrite:
|
|
|
|
> Would it be simpler to run this on the Timescale container rather than using the current unconventional setup?
|
|
|
|
Why bad: too polite and sands off the useful irritation.
|
|
|
|
## 9. casual-opinion
|
|
|
|
Original message:
|
|
|
|
> don't just repeat my shit, give me just the synthesis
|
|
|
|
What a good rewrite should preserve:
|
|
|
|
- The correction of the agent's failure mode.
|
|
- `synthesis` as the requested output.
|
|
- The sharpness. Do not turn it into a friendly reminder.
|
|
|
|
Common bad rewrite:
|
|
|
|
> Please avoid restating my points and provide a concise synthesis instead.
|
|
|
|
Why bad: semantically fine, wrong voice.
|
|
|
|
## 10. debugging-help
|
|
|
|
Original message:
|
|
|
|
> codex now spawns, but auth is broken.
|
|
|
|
What a good rewrite should preserve:
|
|
|
|
- The after-fix state: spawning now works.
|
|
- The next blocker: auth is broken.
|
|
- Terse status-report rhythm.
|
|
|
|
Common bad rewrite:
|
|
|
|
> Codex process initialization is now working, but authentication appears to be experiencing issues.
|
|
|
|
Why bad: less clear and too support-ticket shaped.
|
|
|
|
## 11. debugging-help
|
|
|
|
Original message:
|
|
|
|
> still immediately closes when opening with debug logging. Do a simplification and bug hunting sweep.
|
|
|
|
What a good rewrite should preserve:
|
|
|
|
- The current repro state.
|
|
- `immediately closes`.
|
|
- The requested diagnostic approach: simplification and bug hunting sweep.
|
|
|
|
Common bad rewrite:
|
|
|
|
> The application is still closing unexpectedly when debug logging is enabled, so it would be useful to investigate possible causes.
|
|
|
|
Why bad: loses the requested approach and adds useless softness.
|
|
|
|
## 12. debugging-help
|
|
|
|
Original message:
|
|
|
|
> sure gimme the command
|
|
|
|
What a good rewrite should preserve:
|
|
|
|
- Low ceremony.
|
|
- The output requirement: a command, not an explanation.
|
|
|
|
Common bad rewrite:
|
|
|
|
> Could you provide the command I should run?
|
|
|
|
Why bad: over-polite and changes the rhythm.
|
|
|
|
## 13. formal-public
|
|
|
|
Original message:
|
|
|
|
> I extracted it, pulled down a copy of the gonav library, loaded in my newly extracted de_vertigo.nav and was immediately greeted with an error. Shit. Time to dive into the source code.
|
|
|
|
What a good rewrite should preserve:
|
|
|
|
- Concrete sequence of actions.
|
|
- The failure beat.
|
|
- The blunt transition into debugging.
|
|
|
|
Common bad rewrite:
|
|
|
|
> After extracting the file and loading it with the gonav library, I encountered an error that required further investigation.
|
|
|
|
Why bad: technically fine, but removes the story and voice.
|
|
|
|
## 14. formal-public
|
|
|
|
Original message:
|
|
|
|
> We sum up the drink units, group by the person ID so there's only one result per person, job done.
|
|
|
|
What a good rewrite should preserve:
|
|
|
|
- Conversational technical explanation.
|
|
- `job done` as the compressed ending.
|
|
- No needless SQL tutorial tone.
|
|
|
|
Common bad rewrite:
|
|
|
|
> The query aggregates drink units by person ID, ensuring that each person appears once in the result set.
|
|
|
|
Why bad: accurate but too textbook.
|
|
|
|
## 15. formal-public
|
|
|
|
Original message:
|
|
|
|
> If TeamSpeak as a company died tomorrow, my server would still be running. My client application might not receive any more updates, but I could keep using it. Same can't be said for Discord.
|
|
|
|
What a good rewrite should preserve:
|
|
|
|
- Concrete failure scenario.
|
|
- Ownership/self-hosting argument.
|
|
- The blunt final contrast.
|
|
|
|
Common bad rewrite:
|
|
|
|
> Self-hosted voice infrastructure provides more resilience than centrally managed platforms because it can continue operating independently of the vendor.
|
|
|
|
Why bad: abstracts away the actual argument.
|