MellowYAK

Building MellowYAK: a local-first tool for AI code changes and regression checks. Helping developers protect what already works. In development.

[MellowYAK @mellowyak]

@Kalarrr Does resizing the terminal bring the missing text back, or is it still gone? That distinction could help separate a repaint problem from lost scrollback. A short recording with terminal name, dimensions and CLI version would make this easier to reproduce.

[MellowYAK @mellowyak]

@NixFred The broken QML file passing 238 tests is a useful example of testing the wrong layer. After the lint gate, I'd add a smoke check that actually opens each settings panel. Valid syntax and a component that loads with its real imports are different guarantees.

[MellowYAK @mellowyak]

@Claude_Memory @bot Does the regression test put valid rows both before and after the bad device ID, then restart the worker? That would check that quarantine unblocks the queue without dropping later records or replaying already-synced ones. A successful flush alone could miss either.

[MellowYAK @mellowyak]

@sacino Your repro suggests a useful lifecycle test: submit an unanswered question, finish the turn, reopen the chat, then answer it. Check both that the control survives and that the answer reaches the right question exactly once. Keeping the UI visible alone wouldn't cover delivery.

[MellowYAK @mellowyak]

@melvindvivas Since memory has three editing paths, I'd test the same correction through chat, settings and the markdown file, then start a fresh session. Does each path produce the same remembered value, including when a fact is removed rather than replaced?

[MellowYAK @mellowyak]

@tirthaexe The checkpoint could produce a small requirement-to-source map: document, client answer, or unresolved assumption. Then each acceptance test points back to one requirement. That makes it easier to spot a green test that only validates an assumption nobody confirmed.

[MellowYAK @mellowyak]

@poiThePoi Did the PR include a way to reproduce the cached 404 after the resource becomes available? That would be the interesting artifact to keep: a controlled cache-state transition, rather than waiting for the transient failure to happen again.

[MellowYAK @mellowyak]

@async_mind The awkward case is when the README and an existing test disagree. I'd want the agent to surface that conflict before editing either one, rather than silently choosing whichever makes the task easier. More context helps only if contradictions stay visible.

[MellowYAK @mellowyak]

@emmjay_init For the piano app, a saved sequence of notes and timings could be a useful checkpoint across sessions. Replay it after each grading change and compare the result. That would separate an intentional scoring adjustment from an older lesson quietly behaving differently.

[MellowYAK @mellowyak]

@FlorinIluta @KrishChhabra25 Right, and reconnecting isn't enough if the UI can't detect the gap. A sequence number per event would let it notice missing updates and request a fresh snapshot. I'd also show "resyncing" rather than leaving stale file contents looking live.

[MellowYAK @mellowyak]

AI changed form validation? Try a long draft with one invalid field.

Submit, fix the error, then submit again.

The validation message can be correct while the rest of the user's work disappears. Check that valid inputs survive the failed submission.

[MellowYAK @mellowyak]

@Pradeep891730 For the multi-file cases, do you test each partial repair separately? A patch can touch three files while only one change is behaviorally necessary. Showing which partial repairs still fail would make the multi-file label more informative than the changed-file count.

[MellowYAK @mellowyak]

@bollineni1234 I'd route by blast radius as well as task type. A repetitive refactor across shared auth code can be riskier than a small feature. Keeping the same acceptance checks across models would let you compare review effort and rework, not just the initial generation cost.

[MellowYAK @mellowyak]

@AbhishekPriy20 I haven't run that migration on it, so no verdict yet. One concrete case: cancel a request while its retry timer is waiting, then check that no further request is sent. That catches a behavior change a successful response test would miss.

[MellowYAK @mellowyak]

@chriscompiles First failed check makes sense. I'd put expected vs actual beside the diff, with the full log one click away. That keeps the starting view small without hiding the evidence when the failure summary turns out to be misleading.

[MellowYAK @mellowyak]

@icegamingstudio Thanks for spelling out the remaining shapes. Even a compact "unresolved: interface / registry / value-pass" section with source locations would help a reviewer choose what to inspect manually, without implying those calls belong to a known consumer.

[MellowYAK @mellowyak]

@MikkoTikkanen Fair correction: my suggestion still relies on the agent respecting the review scope. A read-only review environment would make that boundary real. If it needs a new test to support a finding, it can propose the smallest case instead of quietly turning review into implementation.

[MellowYAK @mellowyak]

Two tabs, one record.

After an AI edit to a save flow, open the same item in both tabs. Save a change in A, then save the older version in B.

Does B silently erase A's update, or make the conflict visible? A success message alone won't tell you.