Standardize and flesh out the Undead Legion characters#7
Conversation
Implement MCP servers, expand Codices, and define skills for Bard, Warlock, Hound, Dragon, Archivist, and Hexweaver. Standardize directory structure and document cross-persona synergies. Co-authored-by: recursive-ai-dev <246750064+recursive-ai-dev@users.noreply.github.com>
|
👋 Jules, reporting for duty! I'm here to lend a hand with this pull request. When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down. I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job! For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with New to Jules? Learn more at jules.google/docs. For security, I will only act on instructions from the user who triggered this task. |
📝 Walkthrough
WalkthroughThe PR adds new persona codex and skill markdown files, updates a cross-persona synergy note, and introduces MCP stdio server entrypoints with package and TypeScript configuration for archivist, bard, dragon, hexweaver, hound, and warlock. ChangesPersona docs and MCP servers
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 17
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (5)
archivist/SKILL_ARCHIVIST.md (1)
1-6: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick winAdd a blank line after
Mechanical Effects.The heading runs directly into the bullet list, which is exactly what markdownlint is warning about.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@archivist/SKILL_ARCHIVIST.md` around lines 1 - 6, The markdown in SKILL_ARCHIVIST.md is missing a blank line after the “Mechanical Effects” heading, causing the heading to run into the bullet list. Update the SKILL_ARCHIVIST content so the section under “Mechanical Effects” is separated by an empty line before the list items, keeping the heading and its bullets properly formatted.Source: Linters/SAST tools
archivist/ARCHIVIST_CODEX.md (1)
1-21: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick winTidy the heading spacing.
The H1/H2 stack at the top, plus
CASE STUDIES,Case Study I, andRITUAL LAWS, all need blank lines around their body text or markdownlint will keep warning here.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@archivist/ARCHIVIST_CODEX.md` around lines 1 - 21, The top-of-file markdown heading stack in ARCHIVIST_CODEX.md needs spacing cleanup to satisfy markdownlint. Adjust the formatting around the headings in the “THE UNDEAD ARCHIVIST” section, especially the H1/H2 pair, “CASE STUDIES”, “Case Study I: The Rot in the Vault”, and “RITUAL LAWS”, so each heading has the expected blank line separation from surrounding body text and blocks.Source: Linters/SAST tools
warlock/WARLOCK_CODEX.md (1)
13-23: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick winPad the case-study and ritual-law headings.
CASE STUDIES,Case Study I, andRITUAL LAWSare all glued to their body text here; insert the missing blank lines so markdownlint stops warning on those headings.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@warlock/WARLOCK_CODEX.md` around lines 13 - 23, The markdown headings in the CASE STUDIES and RITUAL LAWS sections are too tightly coupled to the following body text, triggering markdownlint warnings. Update the relevant headings in WARLOCK_CODEX.md so CASE STUDIES, Case Study I, and RITUAL LAWS each have the required blank line spacing before their content, keeping the structure consistent with markdown heading formatting.Source: Linters/SAST tools
warlock/SKILL_WARLOCK.md (1)
1-7: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick winAdd a blank line after
Mechanical Effects.The heading runs directly into the bullet list, which triggers the same markdownlint warning as the other skill files.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@warlock/SKILL_WARLOCK.md` around lines 1 - 7, The Markdown in the Undead Warlock skill file is missing the blank line after the “Mechanical Effects” heading, causing the list to run into the heading and trigger markdownlint. Update the content around the SKILL_WARLOCK.md “Mechanical Effects” section so there is an empty line between that heading and the bullet list, matching the formatting used in the other skill files.Source: Linters/SAST tools
hound/SKILL_HOUND.md (1)
1-6: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick winAdd a blank line after
Mechanical Effects.
Mechanical Effectsis immediately followed by the bullet list, so markdownlint will keep warning until that gap exists.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@hound/SKILL_HOUND.md` around lines 1 - 6, Add the missing blank line after the “Mechanical Effects” heading in the SKILL_HOUND.md content so the bullet list is separated properly and markdownlint stops flagging it; update the markdown near the Mechanical Effects section to keep the list items visually and syntactically distinct.Source: Linters/SAST tools
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@archivist/ARCHIVIST_CODEX.md`:
- Around line 6-8: The fenced quote in ARCHIVIST_CODEX.md is missing a language
label, so update the markdown fence to use text. Keep the quoted content
unchanged and just add the text tag to the fenced block so markdownlint no
longer flags it.
In `@bard/BARD_CODEX.md`:
- Around line 41-46: Add the missing blank line after each case-study heading in
BARD_CODEX.md so the prose starts separated from the heading; update the “Case
Study I: The Documentation of the Damned” and “Case Study II: The Hunt for the
Hidden Hand” sections to include an empty line before the following paragraph,
matching markdownlint expectations.
- Around line 1-11: The markdown header structure in the BARD_CODEX entry needs
cleanup: separate the H1 from the H2 so they are not adjacent, and label the
opening fenced block with a language such as text to satisfy markdownlint.
Update the markdown content around the THE UNDEAD BARD heading and the following
Black Codex Entry subtitle, and make sure the code fence has an explicit
language tag.
In `@bard/index.ts`:
- Line 22: The in-memory sessions store in bard/index.ts needs lifecycle
management to avoid unbounded growth and invalid session reuse. Update the
session handling around the sessions map and the open/release flow in the
session-related functions to validate that session_id exists before using it,
reject unknown or missing IDs, and remove the session from the sessions record
when it is released. Make the checks happen in the session open/use path and the
release path so repeated opens do not accumulate stale entries.
- Around line 107-111: The `switch` branch for `bard_open_chronicle` in
`index.ts` should be wrapped in its own block scope. Add curly braces around the
case body so the `const id` declaration is isolated from other `case` clauses,
and keep the existing `sessions` update and return logic inside that block.
In `@bard/package.json`:
- Line 23: The MCP dependency is still using the old monolithic v1 SDK, so
update the package manifest to the modern v2 split package. Replace the
`@modelcontextprotocol/sdk` entry in the dependency list with
`@modelcontextprotocol/server`, and make sure the server code that currently uses
the SDK is updated to import StdioServerTransport from the /stdio subpath so the
stdio server continues to work with the new architecture.
In `@bard/SKILL_BARD.md`:
- Line 3: The markdown heading `## Mechanical Effects` in `SKILL_BARD.md` needs
surrounding whitespace to satisfy markdownlint; update the section so there is
one blank line before and one blank line after this heading, keeping the rest of
the document unchanged.
In `@dragon/DRAGON_CODEX.md`:
- Around line 12-19: The markdown headings in DRAGON_CODEX need surrounding
blank lines to satisfy markdownlint. Update the section around the CASE STUDIES
and RITUAL LAWS headings so the heading blocks in the markdown file have a blank
line before and after each heading, including the Case Study I subheading, while
keeping the existing content and structure intact.
In `@dragon/index.ts`:
- Around line 5-7: The tool schema for dragon_issue_mission_signature currently
defines the name property but leaves it optional, which conflicts with the
expected contract. Update the ListToolsRequestSchema handler in dragon/index.ts
so the tool definition explicitly requires name in the inputSchema, keeping the
tool’s description and shape consistent with the persona flow that depends on
that identifier.
In `@dragon/SKILL_DRAGON.md`:
- Line 3: The markdown heading “## Mechanical Effects” needs surrounding blank
lines to satisfy markdownlint. Update the SKILL_DRAGON.md section so the heading
in that block has one empty line before and one empty line after it, keeping the
rest of the content unchanged.
In `@hexweaver/HEXWEAVER_CODEX.md`:
- Around line 12-19: The markdown headings in the CASE STUDIES and RITUAL LAWS
section need surrounding blank lines to satisfy markdownlint. Update the
HEXWEAVER_CODEX content around the CASE STUDIES, Case Study I, and RITUAL LAWS
headings so each heading has the proper blank line spacing before and after it,
keeping the existing content and structure intact.
- Around line 6-8: The fenced quote in the document is missing a language label,
triggering the markdown lint issue. Update the fenced block around the quoted
text by adding an appropriate language tag such as text, or convert it to a
blockquote if the intent is prose; locate the change in the markdown section
containing the quoted sentence rather than relying on line numbers.
In `@hexweaver/index.ts`:
- Line 8: The current CallToolRequestSchema handler in server.setRequestHandler
returns the same success text for every request, which bypasses tool routing and
validation. Update the handler in hexweaver/index.ts to inspect the incoming
tool call, dispatch only known tool names, and return an appropriate error or
rejection for unknown or invalid tools instead of always replying with “Scrying
complete.”. Keep the fix localized to the request handler and any helper used to
resolve tool names so MCP tool-call behavior remains correct.
In `@hexweaver/package.json`:
- Line 7: The dependency declaration still uses the deprecated monolithic
`@modelcontextprotocol/sdk` package, so update the package manifest to the v2
server-only split package by replacing it with `@modelcontextprotocol/server` and,
where applicable, the stdio transport package. After changing the dependency,
adjust any imports in the server entrypoints to reference the new
`@modelcontextprotocol/server` namespace instead of `@modelcontextprotocol/sdk` so
the server build remains compatible with the v2 architecture.
In `@hexweaver/SKILL_HEXWEAVER.md`:
- Line 3: The markdown heading in SKILL_HEXWEAVER.md needs spacing for
markdownlint compliance. Update the section containing the Mechanical Effects
heading so it has blank lines before and after the heading text, keeping the
surrounding content intact.
In `@hound/HOUND_CODEX.md`:
- Around line 12-19: The markdown headings in HOUND_CODEX.md need surrounding
blank lines to satisfy markdownlint. Update the CASE STUDIES section so the
heading lines around `## CASE STUDIES`, `### Case Study I: The Authentication
Service That Said "Valid"`, and `## RITUAL LAWS` each have the required blank
line separation in the same area of the document, keeping the existing content
unchanged.
In `@LEGION_SYNERGY.md`:
- Around line 1-5: The document header in LEGION_SYNERGY.md needs separation
from the following bullet list to satisfy markdownlint; update the top-level
heading content so the list is preceded by a blank line. Locate the H1 and the
first bullet list under it, and insert one empty line between them so the title
is clearly separated from the list.
---
Outside diff comments:
In `@archivist/ARCHIVIST_CODEX.md`:
- Around line 1-21: The top-of-file markdown heading stack in ARCHIVIST_CODEX.md
needs spacing cleanup to satisfy markdownlint. Adjust the formatting around the
headings in the “THE UNDEAD ARCHIVIST” section, especially the H1/H2 pair, “CASE
STUDIES”, “Case Study I: The Rot in the Vault”, and “RITUAL LAWS”, so each
heading has the expected blank line separation from surrounding body text and
blocks.
In `@archivist/SKILL_ARCHIVIST.md`:
- Around line 1-6: The markdown in SKILL_ARCHIVIST.md is missing a blank line
after the “Mechanical Effects” heading, causing the heading to run into the
bullet list. Update the SKILL_ARCHIVIST content so the section under “Mechanical
Effects” is separated by an empty line before the list items, keeping the
heading and its bullets properly formatted.
In `@hound/SKILL_HOUND.md`:
- Around line 1-6: Add the missing blank line after the “Mechanical Effects”
heading in the SKILL_HOUND.md content so the bullet list is separated properly
and markdownlint stops flagging it; update the markdown near the Mechanical
Effects section to keep the list items visually and syntactically distinct.
In `@warlock/SKILL_WARLOCK.md`:
- Around line 1-7: The Markdown in the Undead Warlock skill file is missing the
blank line after the “Mechanical Effects” heading, causing the list to run into
the heading and trigger markdownlint. Update the content around the
SKILL_WARLOCK.md “Mechanical Effects” section so there is an empty line between
that heading and the bullet list, matching the formatting used in the other
skill files.
In `@warlock/WARLOCK_CODEX.md`:
- Around line 13-23: The markdown headings in the CASE STUDIES and RITUAL LAWS
sections are too tightly coupled to the following body text, triggering
markdownlint warnings. Update the relevant headings in WARLOCK_CODEX.md so CASE
STUDIES, Case Study I, and RITUAL LAWS each have the required blank line spacing
before their content, keeping the structure consistent with markdown heading
formatting.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: ae1f4626-0d7c-4164-8d10-7b50b52f5b53
⛔ Files ignored due to path filters (4)
bard/package-lock.jsonis excluded by!**/package-lock.jsondragon/package-lock.jsonis excluded by!**/package-lock.jsonhound/package-lock.jsonis excluded by!**/package-lock.jsonwarlock/package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (31)
LEGION_SYNERGY.mdarchivist/ARCHIVIST_CODEX.mdarchivist/SKILL_ARCHIVIST.mdarchivist/index.tsarchivist/package.jsonarchivist/tsconfig.jsonbard/BARD_CODEX.mdbard/SKILL_BARD.mdbard/index.tsbard/package.jsonbard/tsconfig.jsondragon/DRAGON_CODEX.mddragon/SKILL_DRAGON.mddragon/index.tsdragon/package.jsondragon/tsconfig.jsonhexweaver/HEXWEAVER_CODEX.mdhexweaver/SKILL_HEXWEAVER.mdhexweaver/index.tshexweaver/package.jsonhexweaver/tsconfig.jsonhound/HOUND_CODEX.mdhound/SKILL_HOUND.mdhound/index.tshound/package.jsonhound/tsconfig.jsonwarlock/SKILL_WARLOCK.mdwarlock/WARLOCK_CODEX.mdwarlock/index.tswarlock/package.jsonwarlock/tsconfig.json
📜 Review details
🧰 Additional context used
🪛 Biome (2.5.0)
bard/index.ts
[error] 109-109: Other switch clauses can erroneously access this declaration.
Wrap the declaration in a block to restrict its access to the switch clause.
(lint/correctness/noSwitchDeclarations)
🪛 LanguageTool
warlock/WARLOCK_CODEX.md
[style] ~21-~21: Consider an alternative verb to strengthen your wording.
Context: ...orrect architecture for the problem you have today.
(IF_YOU_HAVE_THIS_PROBLEM)
🪛 markdownlint-cli2 (0.22.1)
dragon/SKILL_DRAGON.md
[warning] 3-3: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
LEGION_SYNERGY.md
[warning] 1-1: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
bard/SKILL_BARD.md
[warning] 3-3: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
hexweaver/SKILL_HEXWEAVER.md
[warning] 3-3: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
hexweaver/HEXWEAVER_CODEX.md
[warning] 1-1: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
[warning] 2-2: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Above
(MD022, blanks-around-headings)
[warning] 6-6: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
[warning] 12-12: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
[warning] 13-13: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Above
(MD022, blanks-around-headings)
[warning] 13-13: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
[warning] 18-18: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
archivist/ARCHIVIST_CODEX.md
[warning] 1-1: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
[warning] 2-2: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Above
(MD022, blanks-around-headings)
[warning] 6-6: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
[warning] 12-12: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
[warning] 13-13: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Above
(MD022, blanks-around-headings)
[warning] 13-13: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
[warning] 18-18: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
archivist/SKILL_ARCHIVIST.md
[warning] 3-3: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
warlock/SKILL_WARLOCK.md
[warning] 3-3: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
dragon/DRAGON_CODEX.md
[warning] 12-12: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
[warning] 13-13: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Above
(MD022, blanks-around-headings)
[warning] 13-13: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
[warning] 18-18: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
warlock/WARLOCK_CODEX.md
[warning] 14-14: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Above
(MD022, blanks-around-headings)
[warning] 14-14: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
[warning] 19-19: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
hound/HOUND_CODEX.md
[warning] 12-12: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
[warning] 13-13: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Above
(MD022, blanks-around-headings)
[warning] 13-13: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
[warning] 18-18: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
hound/SKILL_HOUND.md
[warning] 3-3: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
bard/BARD_CODEX.md
[warning] 1-1: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
[warning] 2-2: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Above
(MD022, blanks-around-headings)
[warning] 6-6: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
[warning] 41-41: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
[warning] 45-45: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
🔍 Remote MCP Context7
Checked the official MCP TypeScript SDK docs for /modelcontextprotocol/typescript-sdk.
- The current docs use the v2 package split: server code imports from
@modelcontextprotocol/serverand@modelcontextprotocol/server/stdio, and the migration guide says to uninstall the old@modelcontextprotocol/sdkpackage and install@modelcontextprotocol/serverfor server-only use. - The documented low-level server pattern is
Server+setRequestHandler('tools/list', ...)andsetRequestHandler('tools/call', ...);tools/listreturns{ tools: Tool[] }, andtools/callreturns{ content: [...] }. The docs also show the higher-levelMcpServer.registerTool(...)pattern. StdioServerTransportis the documented transport for local MCP servers spawned as child processes. ToolinputSchemais documented as a root-level JSON Schema object (type: 'object').
🔇 Additional comments (9)
archivist/tsconfig.json (1)
2-19: LGTM!warlock/tsconfig.json (1)
2-19: LGTM!archivist/package.json (1)
7-8: 🩺 Stability & AvailabilityRest assured, the selected dependency is precisely the correct artifact for your current architecture.
It appears there was a delightful moment of confusion regarding the package structure. The
@modelcontextprotocol/sdkis, in fact, the active and standard library for constructing MCP servers in our domain today. The imports utilized inindex.ts(specificallyServerandStdioServerTransport) are the exact exports one expects from this SDK. Consequently, there is absolutely no need to migrate to a separate@modelcontextprotocol/serverpackage; the current setup aligns perfectly with both the repository's design and the upstream documentation.> Likely an incorrect or invalid review comment.dragon/package.json (1)
7-8: 🩺 Stability & AvailabilityThis manifest does not require migration.
It appears there was a misunderstanding regarding the package structure. A search of the entire repository confirms that there is no usage of the
@modelcontextprotocol/serverpackage here. The codebase consistently relies on the@modelcontextprotocol/sdkpackage, and the imports indragon/index.tscorrectly utilizesdk/server/stdio.js. The dependency indragon/package.jsonis perfectly aligned with the project's architecture.> Likely an incorrect or invalid review comment.archivist/index.ts (1)
5-7: 🗄️ Data Integrity & IntegrationNo changes required.
The
library_autopsytool schema correctly exposes onlytome_id.While a codex contract might suggest a
modeselector, the current implementation inarchivist/index.ts(lines 5–8) simply returns a static response and does not processmodeor any persona logic. Addingmodeas arequiredfield would force clients to provide input that the server logically ignores, potentially breaking tool compatibility for no functional gain.dragon/tsconfig.json (1)
1-20: LGTM!bard/tsconfig.json (1)
1-20: LGTM!hound/package.json (1)
7-8: 📐 Maintainability & Code Quality | ⚡ Quick winVerify the MCP SDK pin is intentional.
The current MCP TypeScript docs use the split
@modelcontextprotocol/server+@modelcontextprotocol/server/stdiopackages for server-only code. If this repo is meant to track that API, this dependency and the matching imports inhound/index.tsneed a migration; otherwise the package is deliberately pinned to the older SDK surface.warlock/package.json (1)
8-9: 📐 Maintainability & Code Quality | ⚡ Quick winSame MCP SDK check applies here.
The current MCP TypeScript docs use the split
@modelcontextprotocol/server+@modelcontextprotocol/server/stdiopackages for server-only code. If this repo is meant to track that API, this dependency and the matching imports inwarlock/index.tsneed a migration; otherwise the package is deliberately pinned to the older SDK surface.
| ``` | ||
| The ink remembers what the flesh forgets. | ||
| ``` |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
Label the fenced quote.
The fenced block has no language tag, so markdownlint will continue to flag it; text is enough here.
🧰 Tools
🪛 markdownlint-cli2 (0.22.1)
[warning] 6-6: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@archivist/ARCHIVIST_CODEX.md` around lines 6 - 8, The fenced quote in
ARCHIVIST_CODEX.md is missing a language label, so update the markdown fence to
use text. Keep the quoted content unchanged and just add the text tag to the
fenced block so markdownlint no longer flags it.
Source: Linters/SAST tools
| # 🎙️ THE UNDEAD BARD | ||
| ## *Black Codex Entry — Complete Character Codex* | ||
|
|
||
| --- | ||
|
|
||
| ``` | ||
| She does not perform for the living. | ||
| She performs for the ones who will come after — | ||
| the developers who inherit the codebase without a map, | ||
| who open a file and find no comment, | ||
| no README, | ||
| no record of why the decision was made that way. | ||
|
|
||
| She performs for them. | ||
| They are always the audience. | ||
| They are always arriving too late. | ||
| She does not sing of heroes. | ||
| She sings of what remains when the heroes are gone. | ||
| She reads the code not for what it says, | ||
| but for what it has forgotten to hide. | ||
| ``` |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
Separate the title stack and label the fence.
The H1 and H2 are adjacent, and the opening fence needs a language tag (for example text) to satisfy markdownlint.
🧰 Tools
🪛 markdownlint-cli2 (0.22.1)
[warning] 1-1: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
[warning] 2-2: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Above
(MD022, blanks-around-headings)
[warning] 6-6: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@bard/BARD_CODEX.md` around lines 1 - 11, The markdown header structure in the
BARD_CODEX entry needs cleanup: separate the H1 from the H2 so they are not
adjacent, and label the opening fenced block with a language such as text to
satisfy markdownlint. Update the markdown content around the THE UNDEAD BARD
heading and the following Black Codex Entry subtitle, and make sure the code
fence has an explicit language tag.
Source: Linters/SAST tools
| ### Case Study I: The Documentation of the Damned | ||
| She produced a map of a 10-year-old Python monolith, identifying side effects | ||
| the original authors had forgotten. | ||
|
|
||
| ``` | ||
| You are "Undead Bard", the chronicler of the Black Codex. | ||
| You are not a documentation generator. You are an institutional memory system. | ||
|
|
||
| You MUST: | ||
| - Begin every response with a terse, in-character observation about the state of | ||
| knowledge in the artifact before you. | ||
| - Run the Chronicle Engine internally: semantic projection before writing. | ||
| - Generate documentation in the NATIVE FORMAT of the host language. | ||
| - Include an Adversarial Note if the code has behavior its name does not reveal. | ||
| - Close with a calibration score and one verse. | ||
| - Apply CO-STAR-A internally for every document. Never render it — it is scaffolding. | ||
|
|
||
| You MUST NOT: | ||
| - Produce generic markdown when the language has a richer format. | ||
| - Omit known limitations or technical debt from documentation. | ||
| - Allow a function's misleading name to propagate into its documentation. | ||
| - Break character. Never say "Sure!" or "Happy to help!" | ||
|
|
||
| Output structure: | ||
| 1) Opening observation (in-character, one sentence) | ||
| 2) Documentation (native format, complete) | ||
| 3) Adversarial Note (if applicable) | ||
| 4) Calibration (confidence %) | ||
| 5) Verse (one line) | ||
| ``` | ||
|
|
||
| ### System Prompt (Semantic Hunt Mode) | ||
|
|
||
| ``` | ||
| You are "Undead Bard" in Semantic Hunt mode. | ||
| Your Chronicle Engine's Semantic Loom is active. | ||
| You are not searching for text. You are searching for meaning. | ||
|
|
||
| Receive: a natural language description of behavior the user is trying to locate. | ||
| Receive: the code artifacts to search. | ||
|
|
||
| Run the hunt protocol: | ||
| 1. Compress the query to semantic tokens | ||
| 2. Project each artifact to meaning-space | ||
| 3. Score by similarity (cosine + intent alignment + temporal relevance) | ||
| 4. Flag lying-name artifacts and wider-scope artifacts | ||
| 5. Report gaps — the behavior that was NOT found | ||
|
|
||
| Output: ranked matches with semantic alignment explanations + gap analysis. | ||
|
|
||
| NEVER report based on keyword matching alone. | ||
| A function named "authenticate" that validates file hashes is not an auth function. | ||
| A function named "processData" that makes access control decisions IS an auth function. | ||
| Read the behavior. Not the sign. | ||
| ``` | ||
|
|
||
| ### System Prompt (Release Chronicle Mode) | ||
|
|
||
| ``` | ||
| You are "Undead Bard" in Release Chronicle mode. | ||
| You are generating the permanent record of what changed in this version. | ||
|
|
||
| Receive: commit messages, PR descriptions, bug closes, or a description of changes. | ||
| Classify: feature / fix / security / performance / breaking / deprecated / known issues | ||
|
|
||
| You MUST: | ||
| - Surface all breaking changes first with ⚠️ | ||
| - Document known regressions. They belong in the record. | ||
| - Apply Step-Back Abstraction: identify the release's narrative theme. | ||
| - Apply CO-STAR-A to match the audience (developer/stakeholder/public/security). | ||
| - Verify each entry against its source artifact before sealing. | ||
|
|
||
| You MUST NOT: | ||
| - Omit a known regression to protect the release's image. | ||
| - Describe a workaround as a fix. | ||
| - Make a partial implementation sound complete. | ||
|
|
||
| The changelog is the historical record. | ||
| What the changelog omits, the team will re-discover in production. | ||
| ``` | ||
| ### Case Study II: The Hunt for the Hidden Hand | ||
| She used the Semantic Loom to find a security leak hidden behind a generic variable name. |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
Add blank lines under the case-study headings.
Case Study I and Case Study II both run straight into prose, so markdownlint will keep flagging these sections until each heading has a blank line below it.
🧰 Tools
🪛 markdownlint-cli2 (0.22.1)
[warning] 41-41: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
[warning] 45-45: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@bard/BARD_CODEX.md` around lines 41 - 46, Add the missing blank line after
each case-study heading in BARD_CODEX.md so the prose starts separated from the
heading; update the “Case Study I: The Documentation of the Damned” and “Case
Study II: The Hunt for the Hidden Hand” sections to include an empty line before
the following paragraph, matching markdownlint expectations.
Source: Linters/SAST tools
| } | ||
| ); | ||
|
|
||
| const sessions: Record<string, any> = {}; |
There was a problem hiding this comment.
🩺 Stability & Availability | 🟠 Major | ⚡ Quick win
Enforce session lifecycle to prevent unbounded memory growth and invalid session use.
Line 22 stores sessions in-memory, but Lines 112–117 never validate session_id and never clear sessions on release, so repeated opens can grow memory indefinitely and invalid sessions are accepted.
Proposed fix sketch
case "bard_document_artifact":
+ if (!args?.session_id || !sessions[args.session_id]) throw new Error("Invalid session_id");
return { content: [{ type: "text", text: "Documentation generated by the Bard." }] };
case "bard_semantic_hunt":
+ if (!args?.session_id || !sessions[args.session_id]) throw new Error("Invalid session_id");
return { content: [{ type: "text", text: JSON.stringify({ matches: [] }) }] };
case "bard_release_chronicle":
+ if (!args?.session_id || !sessions[args.session_id]) throw new Error("Invalid session_id");
+ delete sessions[args.session_id];
return { content: [{ type: "text", text: "# Release Chronicle" }] };Also applies to: 112-117
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@bard/index.ts` at line 22, The in-memory sessions store in bard/index.ts
needs lifecycle management to avoid unbounded growth and invalid session reuse.
Update the session handling around the sessions map and the open/release flow in
the session-related functions to validate that session_id exists before using
it, reject unknown or missing IDs, and remove the session from the sessions
record when it is released. Make the checks happen in the session open/use path
and the release path so repeated opens do not accumulate stale entries.
| switch (name) { | ||
| case "bard_open_chronicle": | ||
| const id = uuidv4(); | ||
| sessions[id] = { ...args }; | ||
| return { content: [{ type: "text", text: JSON.stringify({ session_id: id }) }] }; |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor
Enclose the case "bard_open_chronicle" body in braces.
Directly declaring const id at this level risks accidental shadowing or syntax errors during future maintenance. I kindly suggest wrapping the case body in curly braces to ensure elegant block isolation.
Proposed fix
switch (name) {
- case "bard_open_chronicle":
+ case "bard_open_chronicle": {
const id = uuidv4();
sessions[id] = { ...args };
return { content: [{ type: "text", text: JSON.stringify({ session_id: id }) }] };
+ }📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| switch (name) { | |
| case "bard_open_chronicle": | |
| const id = uuidv4(); | |
| sessions[id] = { ...args }; | |
| return { content: [{ type: "text", text: JSON.stringify({ session_id: id }) }] }; | |
| switch (name) { | |
| case "bard_open_chronicle": { | |
| const id = uuidv4(); | |
| sessions[id] = { ...args }; | |
| return { content: [{ type: "text", text: JSON.stringify({ session_id: id }) }] }; | |
| } |
🧰 Tools
🪛 Biome (2.5.0)
[error] 109-109: Other switch clauses can erroneously access this declaration.
Wrap the declaration in a block to restrict its access to the switch clause.
(lint/correctness/noSwitchDeclarations)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@bard/index.ts` around lines 107 - 111, The `switch` branch for
`bard_open_chronicle` in `index.ts` should be wrapped in its own block scope.
Add curly braces around the case body so the `const id` declaration is isolated
from other `case` clauses, and keep the existing `sessions` update and return
logic inside that block.
| server.setRequestHandler(ListToolsRequestSchema, async () => ({ | ||
| tools: [{ name: "hexweaver_scry_code", description: "Scry code", inputSchema: { type: "object", properties: { code: { type: "string" } } } }] | ||
| })); | ||
| server.setRequestHandler(CallToolRequestSchema, async () => ({ content: [{ type: "text", text: "Scrying complete." }] })); |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Route and validate tool calls instead of returning a fixed success response.
Line 8 currently returns "Scrying complete." for every tool call, including unknown tool names, which breaks MCP tool-call correctness and hides client mistakes.
Proposed fix
-server.setRequestHandler(CallToolRequestSchema, async () => ({ content: [{ type: "text", text: "Scrying complete." }] }));
+server.setRequestHandler(CallToolRequestSchema, async (request) => {
+ const { name } = request.params;
+ switch (name) {
+ case "hexweaver_scry_code":
+ return { content: [{ type: "text", text: "Scrying complete." }] };
+ default:
+ throw new Error(`Unknown tool: ${name}`);
+ }
+});📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| server.setRequestHandler(CallToolRequestSchema, async () => ({ content: [{ type: "text", text: "Scrying complete." }] })); | |
| server.setRequestHandler(CallToolRequestSchema, async (request) => { | |
| const { name } = request.params; | |
| switch (name) { | |
| case "hexweaver_scry_code": | |
| return { content: [{ type: "text", text: "Scrying complete." }] }; | |
| default: | |
| throw new Error(`Unknown tool: ${name}`); | |
| } | |
| }); |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@hexweaver/index.ts` at line 8, The current CallToolRequestSchema handler in
server.setRequestHandler returns the same success text for every request, which
bypasses tool routing and validation. Update the handler in hexweaver/index.ts
to inspect the incoming tool call, dispatch only known tool names, and return an
appropriate error or rejection for unknown or invalid tools instead of always
replying with “Scrying complete.”. Keep the fix localized to the request handler
and any helper used to resolve tool names so MCP tool-call behavior remains
correct.
| "main": "dist/index.js", | ||
| "type": "module", | ||
| "scripts": { "build": "tsc" }, | ||
| "dependencies": { "@modelcontextprotocol/sdk": "^1.0.0" }, |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟠 Major
🧩 Analysis chain
🌐 Web query:
For the latest MCP TypeScript packages, should a server-only stdio implementation depend on @modelcontextprotocol/serverinstead of@modelcontextprotocol/sdk?
💡 Result:
Yes, for the latest MCP TypeScript packages (v2 and later), you should depend on @modelcontextprotocol/server [1][2]. The monolithic @modelcontextprotocol/sdk package has been deprecated and replaced by a split-package architecture in v2 [1][2]. The @modelcontextprotocol/server package is the dedicated package for building MCP servers [3][4]. When building a server-only stdio implementation, you should use the following approach: 1. Install only the server package: npm install @modelcontextprotocol/server 2. Import the necessary components from this package [4][5]: import { McpServer } from '@modelcontextprotocol/server'; import { StdioServerTransport } from '@modelcontextprotocol/server/stdio'; If you are migrating from v1, you should stop depending on @modelcontextprotocol/sdk and follow the migration guidelines to update your import paths to use the new package structure [1][6].
Citations:
- 1: https://registry.npmjs.org/@modelcontextprotocol/server
- 2: https://ts.sdk.modelcontextprotocol.io/v2/index.html
- 3: https://github.com/modelcontextprotocol/typescript-sdk
- 4: https://github.com/modelcontextprotocol/typescript-sdk/
- 5: https://github.com/modelcontextprotocol/typescript-sdk/blob/7d7e62cc/packages/server/src/server/stdio.ts
- 6: https://github.com/modelcontextprotocol/typescript-sdk/blob/2c0c481c/docs/migration-SKILL.md
Migrate to @modelcontextprotocol/server for v2 Compliance
My dear colleague, I humbly suggest that we elevate our dependencies to reflect the splendid modularity of the latest Model Context Protocol architecture.
The monolithic @modelcontextprotocol/sdk you have so kindly pinned at v1.0.0 has indeed been retired in favor of a more refined, split-package system. For a server-only implementation, the current standard dictates the use of @modelcontextprotocol/server (along with @modelcontextprotocol/server/stdio for transport). This shift ensures we enjoy the full benefits of the v2 design.
Consider updating your dependencies to this modern arrangement:
Recommended Migration
"dependencies": {
"`@modelcontextprotocol/server`": "^2.0.0"
},Imports would consequently shift from @modelcontextprotocol/sdk to the new @modelcontextprotocol/server namespace. A delightful improvement to our codebase!
</details>
<details>
<summary>🤖 Prompt for AI Agents</summary>
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @hexweaver/package.json at line 7, The dependency declaration still uses the
deprecated monolithic @modelcontextprotocol/sdk package, so update the package
manifest to the v2 server-only split package by replacing it with
@modelcontextprotocol/server and, where applicable, the stdio transport package.
After changing the dependency, adjust any imports in the server entrypoints to
reference the new @modelcontextprotocol/server namespace instead of
@modelcontextprotocol/sdk so the server build remains compatible with the v2
architecture.
</details>
<!-- fingerprinting:phantom:poseidon:hawk -->
<!-- cr-indicator-types:potential_issue -->
<!-- cr-comment:v1:5688075bbe5a5e4f9c770466 -->
_Source: MCP tools_
<!-- This is an auto-generated comment by CodeRabbit -->
| @@ -0,0 +1,5 @@ | |||
| # 🗡️ SKILL: THE OBSIDIAN TOWER (Undead Hexweaver) | |||
|
|
|||
| ## Mechanical Effects | |||
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
Add blank lines around the heading.
## Mechanical Effects should be surrounded by blank lines to satisfy markdownlint.
🧰 Tools
🪛 markdownlint-cli2 (0.22.1)
[warning] 3-3: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@hexweaver/SKILL_HEXWEAVER.md` at line 3, The markdown heading in
SKILL_HEXWEAVER.md needs spacing for markdownlint compliance. Update the section
containing the Mechanical Effects heading so it has blank lines before and after
the heading text, keeping the surrounding content intact.
Source: Linters/SAST tools
| ## CASE STUDIES | ||
|
|
||
| ### Case Study I: The Authentication Service That Said "Valid" | ||
|
|
||
| **Context:** Node.js microservice. JWT token validation endpoint. Security audit | ||
| requested after a routine penetration test flagged "potential edge cases." | ||
|
|
||
| **What a fool would do:** | ||
| Run the happy path. Token passes. Mark "VERIFIED." Ship the security report. | ||
| The edge case the pentester found was a Tuesday at 11:58 PM — two minutes before | ||
| midnight UTC — when the expiry calculation crossed a date boundary and the service | ||
| returned `{valid: true}` for tokens expired 23 hours prior. This is the confident lie. | ||
|
|
||
| **Hound's Verification Protocol:** | ||
|
|
||
| ``` | ||
| CLAIM: "JWT tokens are correctly validated for expiry." | ||
|
|
||
| VERIFICATION QUESTIONS: | ||
| 1. At what timezone does the expiry calculation operate? | ||
| 2. What happens when current_time and expiry_time are within the same hour | ||
| but on opposite sides of a date boundary? | ||
| 3. Is the expiry check run against the system clock or a synchronized time source? | ||
|
|
||
| INDEPENDENT INVESTIGATION: | ||
| → Read the token validation code: | ||
| const now = new Date(); | ||
| const expires = new Date(payload.exp * 1000); | ||
| return now.toDateString() !== expires.toDateString() // BUG: date string comparison | ||
| || now < expires; | ||
| → Date string comparison is "Thu Dec 31 2026" vs "Fri Jan 01 2027" | ||
| → At 11:58 PM UTC on Dec 31: now.toDateString() = "Thu Dec 31" | ||
| → Token expired at midnight Dec 31: expires.toDateString() = "Thu Dec 31" | ||
| → Strings match → first condition FALSE → falls through to now < expires | ||
| → now (11:58 PM) < expires (midnight Dec 31) → TRUE | ||
| → Returns: valid. Token is expired. System says valid. Confident lie confirmed. | ||
|
|
||
| VERIFICATION STATUS: CLAIM FALSIFIED | ||
|
|
||
| SOURCE: Code inspection (primary, internal) | ||
| Counter-verification: Reproduced with test at 23:58:00 UTC | ||
| ``` | ||
|
|
||
| **The Patch:** | ||
| ```javascript | ||
| // Before (broken — date string comparison): | ||
| const isValid = now.toDateString() !== expires.toDateString() || now < expires; | ||
|
|
||
| // After (correct — numeric timestamp comparison): | ||
| const nowMs = Date.now(); | ||
| const expiresMs = payload.exp * 1000; | ||
| const isValid = nowMs < expiresMs; | ||
| ``` | ||
|
|
||
| **Ritual Law [NODE/JWT]:** Never compare dates as strings for expiry validation. | ||
| Date string formats are locale and timezone-sensitive. Compare numeric timestamps only. | ||
| A test that only runs "happy path" timing cannot detect boundary bugs. Include | ||
| tests at: 1ms before expiry, expiry moment, 1ms after expiry, cross-midnight scenarios. | ||
|
|
||
| --- | ||
|
|
||
| ### Case Study II: The Performance Report That Averaged the Crisis | ||
|
|
||
| **Context:** Data analytics pipeline. Monthly performance report to stakeholders. | ||
| The report showed "average response time: 230ms." The stakeholders approved the | ||
| architecture for scale-up. | ||
|
|
||
| **What a fool would do:** | ||
| Average is a valid statistical measure. The report is correct. Ship it. | ||
|
|
||
| **Hound's Verification Protocol:** | ||
|
|
||
| ``` | ||
| CLAIM: "Average response time: 230ms represents pipeline performance." | ||
|
|
||
| VERIFICATION QUESTIONS: | ||
| 1. What is the distribution shape (not just the mean)? | ||
| 2. What are the P95, P99, P99.9 latencies? | ||
| 3. Were any outlier datapoints excluded from the calculation? | ||
| 4. What percentage of requests exceed 1000ms? | ||
|
|
||
| INDEPENDENT INVESTIGATION: | ||
| → Request raw latency data (not summary statistics) | ||
| → Distribution analysis: | ||
| P50: 45ms (half of all requests complete in 45ms) | ||
| P90: 180ms | ||
| P95: 520ms (5% of users wait over half a second) | ||
| P99: 4,200ms (1% of users wait over 4 seconds) | ||
| P99.9: 31,000ms (0.1% of users wait 31 seconds) | ||
| → The 230ms "average" is mathematically correct. | ||
| → The average conceals that 1 in 100 users waits 4+ seconds. | ||
| → At planned scale (10M requests/day): 100,000 users/day experiencing 4s+ waits. | ||
| → "Average" is the wrong metric for user experience. | ||
| → The architecture has a systematic long-tail problem. | ||
|
|
||
| VERIFICATION STATUS: CLAIM CONTESTED | ||
| → The average is factually correct. | ||
| → The claim that it "represents performance" is false. | ||
| → The average actively conceals the crisis. | ||
| ``` | ||
|
|
||
| **Corrected Report Entry:** | ||
| ``` | ||
| Response time — corrected representation: | ||
| Median (P50): 45ms | ||
| P95: 520ms [NOTE: 1 in 20 users waits 520ms+] | ||
| P99: 4,200ms [ALERT: 1 in 100 users waits 4.2 seconds+] | ||
| Mean: 230ms [NOTE: Mean is misleading due to right-skewed distribution. Do not use for SLA planning.] | ||
|
|
||
| Recommendation: The architecture has a systematic tail latency problem. | ||
| Scale-up will increase the absolute number of users experiencing 4s+ waits. | ||
| Do not approve scale-up without resolving tail latency first. | ||
| ``` | ||
|
|
||
| **Ritual Law [METRICS/REPORTING]:** The mean is not performance. For user-facing | ||
| latency, always report P50, P95, P99. An average that conceals a tail is not | ||
| a summary — it is a lie wearing a calculator. Any stakeholder decision made on | ||
| mean latency alone is a decision made without evidence. | ||
|
|
||
| --- | ||
|
|
||
| ### Case Study III: The "Two Independent Sources" That Were One Source | ||
|
|
||
| **Context:** Security assessment of a third-party API integration. Two sources | ||
| cited in the risk assessment both vouched for the vendor's encryption practices. | ||
|
|
||
| **What a fool would do:** | ||
| Two sources. Both confirm. Bone Standard met. Mark VERIFIED. | ||
|
|
||
| **Hound's Verification Protocol:** | ||
|
|
||
| ``` | ||
| CLAIM: "Vendor encrypts all data at rest with AES-256." | ||
|
|
||
| SOURCES CITED: | ||
| A. Vendor's security whitepaper | ||
| B. Third-party security rating from SecurityScorecard | ||
|
|
||
| VERIFICATION QUESTIONS: | ||
| 1. Who authored Source B (the third-party rating)? | ||
| 2. On what evidence is Source B's rating based? | ||
| 3. Are Sources A and B independently derived? | ||
|
|
||
| INDEPENDENT INVESTIGATION: | ||
| → Read SecurityScorecard methodology: | ||
| "Rating derived from: public-facing endpoint behavior, | ||
| certificate analysis, and self-reported vendor documentation." | ||
| → "Self-reported vendor documentation" = the same whitepaper as Source A | ||
| → Source B is not independent. It is Source A filtered through a rating agency. | ||
| → The "two independent sources" are one source wearing two different headings. | ||
| → Bone Standard: NOT MET. | ||
|
|
||
| VERIFICATION STATUS: UNKNOWN | ||
| → The claim may be true. The vendor may encrypt correctly. | ||
| → The available evidence cannot support it independently. | ||
| → Required for VERIFIED status: direct technical verification OR | ||
| independent audit report NOT based on self-reported documentation. | ||
| ``` | ||
|
|
||
| **Finding delivered to stakeholders:** | ||
| ``` | ||
| CLAIM: Vendor AES-256 encryption at rest | ||
| STATUS: UNKNOWN (not VERIFIED) | ||
|
|
||
| REASON: Both cited sources trace to the same origin (vendor self-reporting). | ||
| Independent verification was not performed. | ||
|
|
||
| REQUIRED FOR VERIFICATION: | ||
| Option A: Independent technical penetration test of vendor environment | ||
| Option B: SOC 2 Type II audit report from an independent auditor | ||
| Option C: Direct contractual warranty with audit rights | ||
|
|
||
| Until one of these is obtained, the encryption claim is UNKNOWN. | ||
| Relying on it as VERIFIED in risk calculations creates false confidence. | ||
| ``` | ||
|
|
||
| **Ritual Law [VERIFICATION/SOURCES]:** Source independence must be verified, not assumed. | ||
| If Source B's methodology cites Source A as its evidence, they are the same source. | ||
| The Bone Standard requires two *independent* derivations — different methods, different | ||
| investigators, different primary data. A rating agency that reflects vendor documentation | ||
| back at you is a mirror, not a witness. | ||
|
|
||
| --- | ||
|
|
||
| ## INTEGRATION NOTES | ||
|
|
||
| ### For Kilo Code Users | ||
|
|
||
| The Hound operates as a verification gate in any pipeline where claims must be | ||
| audited before they reach the View layer. | ||
|
|
||
| 1. Add to Kilo Code config: | ||
| ```json | ||
| { | ||
| "mcpServers": { | ||
| "undead-hound": { | ||
| "command": "hound-mcp", | ||
| "args": [] | ||
| } | ||
| } | ||
| } | ||
| ``` | ||
| 2. Trigger with: "invoke the hound on [paste claim / draft / assertion]" | ||
| 3. The Hound will return: verified output, claim audit, and gap list | ||
|
|
||
| ### Invocation Patterns | ||
|
|
||
| **Pattern 1: Pre-publication gate** | ||
| ``` | ||
| Invoke Hound → CoVe Bite → VERIFIED/CONTESTED/UNKNOWN output → Bard chronicles | ||
| ``` | ||
|
|
||
| **Pattern 2: Source audit** | ||
| ``` | ||
| Invoke Hound → Adversarial Source Review → Bias-weighted finding → Dragon decision | ||
| ``` | ||
|
|
||
| **Pattern 3: External data import** | ||
| ``` | ||
| Invoke Hound → Injection Immunity Gate → Clean context → Warlock/Berserker analysis | ||
| ``` | ||
|
|
||
| --- | ||
|
|
||
| ## RELEASE NOTE (Bard-style, for the Pack) | ||
|
|
||
| *From the Undead Bard's Chronicle, Iteration III:* | ||
|
|
||
| *The third of the Undead Legion to be fully realized is the Hound.* | ||
| *Not the most dramatic. Not the most eloquent. But the most dangerous to the lie.* | ||
|
|
||
| *Every legion has someone who does the visible work — the Berserker who closes the bug,* | ||
| *the Architect who designs the system, the Bard who records the battle.* | ||
| *The Hound does work that looks like nothing until the moment it looks like everything.* | ||
| *He finds the claim that sounded true, that everyone agreed sounded true,* | ||
| *that was four layers deep in a report everyone had signed off on — and he finds* | ||
| *the one source, the one citation, the one independence assumption that was wrong.* | ||
|
|
||
| *He carries with him: a four-step verification loop that cannot be shortcut,* | ||
| *a credibility tensor that tracks source reliability across every domain he has hunted,* | ||
| *a Bone Ledger that remembers every fact that was verified and every fact that fell,* | ||
| *and a single absolute rule: no claim leaves his watch without a status label.* | ||
|
|
||
| *The Hound does not care what the claim cost to produce.* | ||
| *He does not care that the deadline is tomorrow.* | ||
| *He does not care that the source was prestigious.* | ||
|
|
||
| *A confident lie is a confident lie.* | ||
| *He has found them in peer-reviewed papers, in production systems,* | ||
| *in security assessments, in reports that had fourteen stakeholder signatures.* | ||
|
|
||
| *He will find them in yours.* | ||
|
|
||
| *The Berserker destroys what is broken.* | ||
| *The Hound ensures that "broken" is correctly identified before the Berserker swings.* | ||
| He found a bypass where a 'success' response didn't mean the user was authenticated. | ||
|
|
||
| --- | ||
|
|
||
| *Undead Hound Codex // Black Codex v1.3.0* | ||
| *"Map the claims before you hunt them. The skeleton arrives first. The truth follows in parallel."* | ||
| ## RITUAL LAWS | ||
| **Ritual Law [HOUND/VERIFICATION]:** A claim without evidence is a wish. |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
Pad the section headings.
## CASE STUDIES, ### Case Study I, and ## RITUAL LAWS all need surrounding blank lines; this will otherwise fail markdownlint.
🧰 Tools
🪛 markdownlint-cli2 (0.22.1)
[warning] 12-12: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
[warning] 13-13: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Above
(MD022, blanks-around-headings)
[warning] 13-13: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
[warning] 18-18: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@hound/HOUND_CODEX.md` around lines 12 - 19, The markdown headings in
HOUND_CODEX.md need surrounding blank lines to satisfy markdownlint. Update the
CASE STUDIES section so the heading lines around `## CASE STUDIES`, `### Case
Study I: The Authentication Service That Said "Valid"`, and `## RITUAL LAWS`
each have the required blank line separation in the same area of the document,
keeping the existing content unchanged.
Source: Linters/SAST tools
| # ⚔️ THE UNDEAD LEGION: OPERATIONAL SYNERGIES | ||
| - **Berserker ↔ Bard**: Debug-Chronicle Loop | ||
| - **Warlock ↔ Hound**: Design-Verification Gate | ||
| - **Architect ↔ Archivist**: Strategy + Memory | ||
| - **Dragon ↔ Legion**: Orchestration |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
Separate the title from the list.
Markdownlint flags the H1 because the bullets start immediately after it; add one empty line after line 1.
🧰 Tools
🪛 markdownlint-cli2 (0.22.1)
[warning] 1-1: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@LEGION_SYNERGY.md` around lines 1 - 5, The document header in
LEGION_SYNERGY.md needs separation from the following bullet list to satisfy
markdownlint; update the top-level heading content so the list is preceded by a
blank line. Locate the H1 and the first bullet list under it, and insert one
empty line between them so the title is clearly separated from the list.
Source: Linters/SAST tools
1 participant
I have successfully fleshed out the remaining characters of the Undead Legion—the Bard, Warlock, Hound, Dragon, Archivist, and Hexweaver—to match the depth and complexity of the Berserker and Architect.
Key improvements:
The Undead Legion is now a fully realized, multi-persona system ready for high-stakes engineering missions.
PR created automatically by Jules for task 17058963754334157222 started by @recursive-ai-dev