fix(mcp): allow multi-line description in capture_inbox#17
Merged
Conversation
capture_inbox validated description with the strict single-line check (goal.ContainsControlChars), so any description containing a newline was rejected with "description must not contain control characters". The hermes proposal-loop pushes descriptions formatted as multi-line Markdown (blank-line paragraphs, bullet lists) per the capture format contract, so every surfaced proposal push has failed since this validation went live (21 items stuck retrying). Description is multi-line Markdown prose, the same shape as content body and review_note, which are already validated with containsProseControlChars (rejects all control chars except HT/LF/CR). Apply the same predicate to capture_inbox description. Title stays on the strict single-line check. Adds a regression test that a multi-line bulleted description passes validateCaptureInput.
🤖 Augment PR SummarySummary: Allows multi-line Markdown descriptions in the MCP 🤖 Was this summary useful? React with 👍 or 👎 |
![augmentcode[bot]](https://avatars.githubusercontent.com/in/1027498?s=60&v=4){kind=small}
|
|
||
| func TestCaptureInbox_MultilineDescription(t *testing.T) { | ||
| // Description is multi-line Markdown prose (rendered as paragraphs and | ||
| // bullets), so LF/CR/HT are legitimate — same treatment as content body. |
There was a problem hiding this comment.
TestCaptureInbox_MultilineDescription’s comment mentions allowing LF/CR/HT, but the test input only exercises \n; this could miss a future regression where \r or \t gets rejected despite the intent documented here.
Severity: low
🤖 Was this useful? React with 👍 or 👎, or 🚀 if it prevented an incident/outage.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
capture_inboxvalidatesdescriptionwith the strict single-line check (goal.ContainsControlChars), which rejects LF. The hermes proposal-loop pushes descriptions as multi-line Markdown (blank-line paragraphs,-bullets) per the capture format contract, so every surfaced proposal push has failed withdescription must not contain control characterssince the validation went live — 21 proposals are currently stuck retrying on every loop (5x/day since 06-25), and the failure was silent on the hermes side.Fix
Validate
descriptionwithcontainsProseControlChars(rejects every control char except HT/LF/CR) — the same predicate the codebase already applies to the other multi-line prose fields, contentbodyandreview_note(seeinternal/content/admin.godoc comments).titlestays on the strict single-line check.One-line change + regression test that a multi-line bulleted description passes
validateCaptureInput.Verification
go vet ./internal/mcp/clean,go test ./internal/mcp/all pass.scripts/koopa0-capture.shagainst mcp.koopa0.dev returns the control-characters tool error; a single-line description succeeds.After merge + deploy, the hermes proposal-loop backlog drains itself on the next run (push retry is built in), no hermes-side change required.