new CLAUDE.md, gin server docs, and claude code in CI!

[allisoneer]

Important

Adds CLAUDE.md for ACP codebase guidance and gin-servers.md for Gin server best practices, focusing on code organization and separation of concerns.

• New Documentation:
  • Adds CLAUDE.md with guidance for working on the Agent Control Plane (ACP) codebase, covering project context, documentation, building, code organization, task-specific guidance, testing, and code style.
  • Introduces gin-servers.md for best practices in using Gin servers, focusing on separating business logic from Gin handlers.
• Best Practices:
  • CLAUDE.md emphasizes following existing patterns, using comprehensive documentation, and adhering to Kubernetes conventions.
  • gin-servers.md advises moving business logic out of Gin handlers to improve readability and testability.

^{This description was created by for fa6ad07. You can customize this summary. It will automatically update as commits are pushed.}

[ellipsis-dev]

Caution

Changes requested ❌

Reviewed everything up to fa6ad07 in 1 minute and 51 seconds. Click for details.

• Reviewed 681 lines of code in 2 files
• Skipped 0 files when reviewing.
• Skipped posting 6 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. acp/docs/gin-servers.md:6

• Draft comment:
  Fix grammar: change 'that be used' to 'that can be used' to improve clarity.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 30% vs. threshold = 50% While this is a valid grammar correction, our rules state we should not make purely informative comments. Grammar fixes in documentation, while helpful, don't affect code functionality. However, since this is a new file being added, fixing the grammar now would improve the quality of the documentation from the start. The comment is purely about documentation quality, not code quality. It could be argued that such minor grammar fixes could be handled in a different way. Since this is a new file being added to the codebase, it's better to get the documentation right from the start rather than letting grammar issues persist. While we generally avoid purely informative comments, this grammar fix would improve the quality of new documentation being added to the codebase.

2. acp/docs/gin-servers.md:21

• Draft comment:
  Correct grammar: 'all gin endpoint' should be 'all Gin endpoints' to maintain proper pluralization and capitalization.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% The comment is purely informative, focusing on grammar correction. It doesn't provide a code suggestion or address a potential issue in the code logic.

3. acp/docs/gin-servers.md:79

• Draft comment:
  Avoid variable shadowing in createUserHandler; the 'user' variable declared earlier is shadowed by the one returned from createUser. Consider renaming one of them for clarity.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% Variable shadowing can lead to bugs and make code harder to understand. However, in this case, the shadowing is very localized within a small function, and the flow is clear - we're taking the input user, passing it to createUser, and getting back a potentially modified user. The shadowing actually makes sense here as it represents the transformation of the user object. The shadowing might actually be intentional here to indicate that we're getting back a new/modified user object. The code is quite readable as is. While variable shadowing can be problematic, in this specific case it's not causing confusion and might even help convey the transformation happening. The comment should be removed as it suggests a change that wouldn't necessarily improve the code and the current implementation is clear and intentional.

4. acp/docs/gin-servers.md:2

• Draft comment:
  Typo: "doc of it's own" should be "doc of its own".
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While the comment is technically correct (it's = it is, its = possessive), this is a very minor grammatical issue in a comment line. The meaning is perfectly clear either way. The rules state not to make comments that are obvious or unimportant. Grammar fixes in comments, especially in documentation files, are generally not important enough to warrant a PR comment. Grammar issues could affect documentation quality and readability. Documentation is meant to be professional and polished. While documentation quality matters, this tiny grammatical issue doesn't impact understanding and isn't worth the overhead of a PR comment and revision cycle. Delete this comment as it points out an unimportant grammatical issue that doesn't impact code quality or functionality.

5. acp/docs/gin-servers.md:6

• Draft comment:
  Typo: "context object that be used" likely needs a verb such as "can be used".
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While this is technically correct, PR comments should focus on substantive code issues rather than minor grammatical fixes in documentation. The meaning is still clear despite the typo. The rules specifically say not to make obvious or unimportant comments. The grammar error does make the documentation less professional, and fixing it would improve readability. However, this is exactly the kind of minor, obvious fix that clutters PR reviews and distracts from more important issues. The author can catch this in a basic proofreading pass. Delete this comment as it points out a trivial grammatical issue rather than a substantive code problem.

6. acp/docs/gin-servers.md:21

• Draft comment:
  Typo: "all gin endpoint should be short" should be "all gin endpoints should be short".
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% Since this is a new documentation file, having correct grammar is somewhat important for readability and professionalism. However, the typo is very minor and the meaning is still completely clear. The rules say not to make comments that are obvious or unimportant. Grammar fixes in docs, while nice to have, are probably too minor to warrant a PR comment. Documentation should be held to a high standard of correctness. Poor grammar could reflect badly on the project's quality. While documentation quality matters, this particular fix is extremely minor and doesn't impact understanding. The PR review process shouldn't be cluttered with such trivial corrections. Delete this comment as it's too minor and doesn't materially improve the code or documentation quality enough to warrant a PR comment.

Workflow ID: wflow_AVKPe31jLyNeHsGk

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}