Here is the line that changed my project:
Next · Generate draft
That's a label on a button in a terminal UI. It appeared ...
For further actions, you may consider blocking this person and/or reporting abuse
Forcing the author to write working.md directly keeps the voice grounded. The place where an assistant model genuinely speeds up that phase is checking notes against the brief before drafting starts. When drafting technical walk-throughs, noticing mid-paragraph that an outline claim contradicts a CLI reproduction note burns a lot of momentum. Running verification against the research notes before touching the editor catches those factual gaps while keeping the prose entirely human.
That mid-paragraph moment is the worst, because by then you're attached to the sentence. Right now Meldr only checks claims once there's prose in working.md, so it would catch that contradiction after I'd already written it. Checking the outline against the research notes before drafting would catch it earlier, and it still fits the rule that the model proposes and I decide, since nothing gets written for me. I'm adding it to my list. but do you run that check by hand, or do you have something doing it for you?
Refusing to review a title-only file is a nice guard, but I wonder where the line sits once there's more than a title. Someone could put one sentence under each heading of the approved outline, ask for review, and get back proposals that add up to the draft the button used to generate, just delivered in pieces. Is the check about length, or about whether review proposals may add new content versus only reshape what's already there? The second sounds harder to enforce but closer to what you're after.
woah you found the real loophole. The guard today is basically "is there prose here, or just a title," so one sentence under each heading would get past it, and nothing in review stops a proposal from adding new material. You could rebuild the old button in pieces.
I'm okay with part of that. I can't stop someone who's determined to have a model write their article, and I don't think that's the tool's job. What I care about is the default path. But your second framing is closer to what I'm after: review should reshape what's already there, and new content should only show up when I explicitly ask for help on a section. The cheap way to enforce that is probably a cap on how much a review proposal can grow a section. Going to think about that one. Thanks for pushing on it!
A growth cap is cheap and I think it gets you most of the way. The case it misses is a proposal that keeps the length flat but swaps your sentences for new ones, so a word-count cap could pair with a check on how many of the original sentences survive the review. That said, I agree with where you drew the line: the tool can't stop someone determined, it can only make the honest route the easy one. A cap that makes "rewrite my section from scratch" feel like an explicit request rather than a side effect seems like exactly that.
Keeping claim reports separate from revisions is a useful boundary. One edge case for the digest check: two proposals reviewed against the same working.md are both initially valid, but accepting the first should make the second stale. Do you test that path? I'd also include a write failure after acceptance begins and check that neither a partial article nor a falsely "accepted" proposal is left behind. That would exercise the acceptance contract rather than only edits made between review and accept.
Thanks, this is a useful edge case. The two-proposal path should be covered by the digest check, since accepting the first changes working.md and makes the second stale, BUT I don't have a test for it yet and I'll add one. I'm going to write to a temp file and rename it over working.md, mark the proposal accepted only afterward, and add tests that fail at each step to confirm nothing partial is left behind
Separating verification from drafting makes a lot of sense, especially keeping claim reports outside the document itself. Once a model inserts unverified claims into prose, editing usually turns into fact checking every clause after the fact. Treating claims as an open checklist keeps the actual working text much cleaner.
Checking every sentence after the fact is exactly what I wanted to avoid. Once a shaky claim is sitting inside polished prose, it looks as trustworthy as everything around it. As a checklist it stays visibly unfinished until I've actually checked it
Review-only is where I got value too: on a bench of 24 runs, the review pass produced exactly one note worth keeping, a pre-existing reuse-after-close bug the change had not caused. Everything else was restatement. Do you keep the rejected proposals anywhere, or is that signal gone once you decline?
One keeper out of 24 is a useful number to have. In Meldr, proposals are written to revisions/ as plain Markdown, and declining one doesn't delete it, so the record is there. What I'm not doing yet is anything with it. An accept rate by proposal type would tell me which parts of review are mostly restatement, and those are the parts worth turning down or cutting
Usually when I use AI to write an article, I could tell it to write a full blown article on the topic, and then I start changing things to make it sound more like something I will write, or better still, I don't even use AI all together, and I still come out with a pretty decent article.
I guess the reason I do the second option is to keep harnessing my ability to write articles, and not outsource it entirely to AI
Yes exactly! I do the former as well with shorter articles / opinion pieces that don't require much research, it's easy and tempting. I love writing. I went to school for it. I want AI to enhance my writing without replacing it
It's to find the balance, and know when to bring AI into the process. AI should be part of the system, not the entire system
Does an edit to an unrelated section invalidate every pending proposal, or does Meldr scope the SHA check to the section it touches?
Right now any edit invalidates every pending proposal. The digest covers the whole working.md, so Meldr can't tell an unrelated edit from a conflicting one. That's the simple and safe version, and the cost is exactly what you're pointing at: fixing a typo in section 1 throws out a still-valid proposal for section 4. Scoping the digest to the section a proposal touches is the obvious next step if that gets annoying in practice.