Repository navigation
OSS Release Scaffolding (Cycle 0026) - #13
Conversation
Add standard GitHub OSS files (LICENSE, CONTRIBUTING, SECURITY, NOTICE), ARCHITECTURE.md, and CLI/MCP reference documentation.
- LICENSE, CONTRIBUTING, SECURITY, NOTICE must exist - ARCHITECTURE.md must describe source layout - README must reference all CLI commands and MCP tools
- LICENSE: Apache 2.0 - NOTICE: copyright attribution - SECURITY.md: vulnerability reporting policy - CONTRIBUTING.md: how to participate, code style, commit conventions - ARCHITECTURE.md: source layout, key modules, CLI commands, MCP tools - README.md: added method mcp, sync github, sync ship to command table; added MCP tools reference section 122 tests pass (119 prior + 3 new).
Hill met. LICENSE, CONTRIBUTING, SECURITY, NOTICE, ARCHITECTURE.md, CLI/MCP reference in README. 122 tests pass. No drift. No new debt.
Summary by CodeRabbitRelease Notes
WalkthroughThis PR establishes foundational open-source project governance and reference documentation: adding standard repository files (LICENSE, CONTRIBUTING.md, SECURITY.md, NOTICE), architecture documentation, design cycle artifacts, and test assertions verifying the presence and content of these governance and documentation files. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 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 |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3301ac2639
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| METHOD uses OS-native keychains for secrets management via | ||
| `@git-stunts/vault` when available. GitHub tokens in `.method.json` |
There was a problem hiding this comment.
This statement says METHOD stores secrets in OS keychains via @git-stunts/vault, but the current code path reads credentials directly from .method.json and GITHUB_TOKEN/GITHUB_REPO env vars (src/config.ts), and there is no vault integration in the repo. That mismatch is a security-documentation regression: users may assume stronger secret handling than actually exists and keep sensitive tokens in plaintext config files based on incorrect guidance.
Useful? React with 👍 / 👎.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 10
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@CONTRIBUTING.md`:
- Around line 44-50: The markdown code fence for the commit messages in
CONTRIBUTING.md is missing a language specifier which triggers markdownlint
MD040; update the triple-backtick fence to include a language identifier (e.g.,
change ``` to ```text) around the commit-message block so the fence becomes
```text and the linter stops flagging it; locate the commit-message block in
CONTRIBUTING.md (the triple-backtick fenced block containing lines like "feat:
add near-miss hints to drift detector") and add the language token.
In `@docs/design/0026-oss-release-scaffolding/oss-release-scaffolding.md`:
- Around line 51-54: The "Non-goals" section currently uses checkbox markdown
which creates semantic confusion; update the "Non-goals" under the "Non-goals"
header to use plain bullet points (e.g., "- Comprehensive API reference
(JSDoc/typedoc level)." and "- Tutorial or getting-started guide (that's a
separate cycle).") to match the README.md template's non-checkbox format, or
alternatively add a single sentence explicitly defining the checkbox semantics
for non-goals if you prefer to keep checkboxes; edit the "Non-goals" header and
its two items accordingly to remove ambiguity.
- Around line 34-36: The acceptance criteria for ARCHITECTURE.md are ambiguous;
update the doc and tests/docs.test.ts to make the requirement binary: either (A)
enumerate an exhaustive list of required sections (e.g., "Overview", "Source
layout", "Key modules", "Dependencies", "Deployment", etc.) and change the line
to "ARCHITECTURE.md MUST contain the following sections: <list>", or (B) state
these three are the minimum required and add "At minimum, ARCHITECTURE.md MUST
contain: Overview, Source layout, Key modules" and allow additional sections;
then adjust tests/docs.test.ts to assert the exact behavior you choose (check
for the exhaustive list if you pick A, or check only for the three minimum
headers if you pick B).
- Around line 29-30: Update the two checklist items "- [ ] The CLI commands are
documented with usage, flags, and examples." and "- [ ] The MCP tools are
documented with parameters and descriptions." to specify the exact target files
(e.g., "README.md", "ARCHITECTURE.md", or both) where the documentation must
exist, and rephrase the playback questions so they reference those specific
documents and can be answered unambiguously with yes/no (for example: "Are CLI
commands documented in README.md with usage, flags, and examples?"). Ensure
references to the target documents are explicit and consistent so the checks are
deterministic.
- Line 10: The document contains a redundant "Legend: PROCESS" prose declaration
that duplicates the YAML front-matter legend; in the file's content remove the
repeated prose legend (the "Legend: PROCESS" line) so the YAML front-matter
remains the single source of truth, or alternatively update the
YAML/front-matter convention and the prose to intentionally differ if
duplication is required—make the change near the prose legend occurrence
referenced by the comment to eliminate the DRY violation.
In `@docs/method/retro/0026-oss-release-scaffolding/witness/verification.md`:
- Line 12: Two fenced code blocks are untyped which triggers markdownlint MD040;
update each untyped triple-backtick fence that contains the lines starting with
"method@0.2.0 test" and the block starting with "Playback-question drift found."
to include a language tag (e.g., use ```text) so both blocks read as fenced with
a language and satisfy the linter.
In `@README.md`:
- Around line 471-480: The MCP tool table entries are too vague—update each row
to match the implementations in src/mcp.ts: replace method_status with a
description like "Return workspace state (backlog lanes, active cycles, legend
health) as structured JSON"; change method_pull to "Promote a backlog item into
the next numbered cycle"; change method_drift to "Check active cycle playback
questions against tests to detect drift"; change method_sync_ship to "Perform
ship sync and update CHANGELOG.md and BEARING.md"; and change
method_capture_witness to "Automate terminal evidence capture for a cycle
(verification witness)"; ensure each tool name (method_status, method_pull,
method_drift, method_sync_ship, method_capture_witness) is referenced exactly as
in src/mcp.ts so the README matches the code.
- Line 468: Update the README's description for the workspace parameter to match
the implementation: replace "absolute path to the workspace root" with the exact
phrasing used by the implementation for the workspace parameter—"Absolute path
to the METHOD workspace root directory"—so the README's `workspace` parameter
text matches the definition in mcp.ts.
- Line 462: Update the README table row so the command cell clearly indicates
the actual lowercase CLI token while the Purpose cell keeps the branded
capitalization: leave the command display as `method sync github` but append a
short parenthetical like "(command uses lowercase 'github')" next to it, and
ensure the Purpose remains "Sync backlog with GitHub Issues"; update the table
header or add a brief note if you prefer to document syntax-vs-brand rules
consistently across the commands list.
In `@SECURITY.md`:
- Around line 27-30: Remove the false claim about OS-native keychain support via
`@git-stunts/vault` from SECURITY.md and replace it with an accurate statement
that no keychain/vault integration exists in the codebase (no
`@git-stunts/vault` dependency and no vault code in src/), explicitly note that
the GitHub adapter stores tokens as private properties and sends them as Bearer
tokens, and instruct users to treat `.method.json` as sensitive (add it to
`.gitignore` if it contains credentials) and to use an external OS keychain or
secrets manager if they need true secret storage.
🪄 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: 8b38f5df-7f3f-4d6e-af8d-75ca4c97ee71
📒 Files selected for processing (10)
ARCHITECTURE.mdCONTRIBUTING.mdLICENSENOTICEREADME.mdSECURITY.mddocs/design/0026-oss-release-scaffolding/oss-release-scaffolding.mddocs/method/retro/0026-oss-release-scaffolding/oss-release-scaffolding.mddocs/method/retro/0026-oss-release-scaffolding/witness/verification.mdtests/docs.test.ts
| ``` | ||
| feat: add near-miss hints to drift detector | ||
| fix: resolve symlink in CLI entry point guard | ||
| test: RED — failing tests for async exec refactor | ||
| chore: ship sync for cycles 0022-0025 | ||
| docs: update VISION.md for cycles 0001-0025 | ||
| ``` |
There was a problem hiding this comment.
Specify the language for the commit-message code fence.
This currently triggers markdownlint MD040.
Suggested patch
-```
+```text
feat: add near-miss hints to drift detector
fix: resolve symlink in CLI entry point guard
test: RED — failing tests for async exec refactor
chore: ship sync for cycles 0022-0025
docs: update VISION.md for cycles 0001-0025</details>
<details>
<summary>🧰 Tools</summary>
<details>
<summary>🪛 markdownlint-cli2 (0.22.0)</summary>
[warning] 44-44: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
</details>
</details>
<details>
<summary>🤖 Prompt for AI Agents</summary>
Verify each finding against the current code and only fix it if needed.
In @CONTRIBUTING.md around lines 44 - 50, The markdown code fence for the commit
messages in CONTRIBUTING.md is missing a language specifier which triggers
markdownlint MD040; update the triple-backtick fence to include a language
identifier (e.g., change totext) around the commit-message block so the
fence becomes ```text and the linter stops flagging it; locate the
commit-message block in CONTRIBUTING.md (the triple-backtick fenced block
containing lines like "feat: add near-miss hints to drift detector") and add the
language token.
</details>
<!-- fingerprinting:phantom:poseidon:hawk -->
<!-- This is an auto-generated comment by CodeRabbit -->
|
|
||
| Source: dogfood discovery — missing standard GitHub OSS files and | ||
| reference documentation for CLI and MCP. | ||
| Legend: PROCESS |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Redundant legend declaration.
Line 10 repeats the legend already declared in the YAML front-matter at line 3. This violates DRY. Either remove the prose legend declaration or establish a convention that justifies the duplication.
♻️ Proposed fix to remove redundancy
Source: dogfood discovery — missing standard GitHub OSS files and
reference documentation for CLI and MCP.
-Legend: PROCESS🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/design/0026-oss-release-scaffolding/oss-release-scaffolding.md` at line
10, The document contains a redundant "Legend: PROCESS" prose declaration that
duplicates the YAML front-matter legend; in the file's content remove the
repeated prose legend (the "Legend: PROCESS" line) so the YAML front-matter
remains the single source of truth, or alternatively update the
YAML/front-matter convention and the prose to intentionally differ if
duplication is required—make the change near the prose legend occurrence
referenced by the comment to eliminate the DRY violation.
| - [ ] The CLI commands are documented with usage, flags, and examples. | ||
| - [ ] The MCP tools are documented with parameters and descriptions. |
There was a problem hiding this comment.
Playback questions lack precision about documentation location.
Lines 29-30 state that "CLI commands are documented" and "MCP tools are documented" but fail to specify WHERE. Playback questions must be precise enough to answer with definitive yes/no. Without specifying the target documents (README.md, ARCHITECTURE.md, or both), these questions allow ambiguous interpretation.
✨ Proposed fix to add location specificity
-- [ ] The CLI commands are documented with usage, flags, and examples.
-- [ ] The MCP tools are documented with parameters and descriptions.
+- [ ] The CLI commands are documented in README.md with usage, flags, and examples.
+- [ ] The MCP tools are documented in README.md and ARCHITECTURE.md with parameters and descriptions.📝 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.
| - [ ] The CLI commands are documented with usage, flags, and examples. | |
| - [ ] The MCP tools are documented with parameters and descriptions. | |
| - [ ] The CLI commands are documented in README.md with usage, flags, and examples. | |
| - [ ] The MCP tools are documented in README.md and ARCHITECTURE.md with parameters and descriptions. |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/design/0026-oss-release-scaffolding/oss-release-scaffolding.md` around
lines 29 - 30, Update the two checklist items "- [ ] The CLI commands are
documented with usage, flags, and examples." and "- [ ] The MCP tools are
documented with parameters and descriptions." to specify the exact target files
(e.g., "README.md", "ARCHITECTURE.md", or both) where the documentation must
exist, and rephrase the playback questions so they reference those specific
documents and can be answered unambiguously with yes/no (for example: "Are CLI
commands documented in README.md with usage, flags, and examples?"). Ensure
references to the target documents are explicit and consistent so the checks are
deterministic.
| - [ ] `tests/docs.test.ts` proves the required OSS files exist. | ||
| - [ ] `tests/docs.test.ts` proves ARCHITECTURE.md contains expected | ||
| sections (overview, source layout, key modules). |
There was a problem hiding this comment.
Ambiguous acceptance criteria for ARCHITECTURE.md sections.
Line 35-36 states that tests must prove "ARCHITECTURE.md contains expected sections (overview, source layout, key modules)" but the parenthetical is ambiguous—are these examples or the complete list? Playback questions must be binary. Either enumerate the exhaustive list of required sections or state that these are minimum examples with additional sections allowed.
🎯 Proposed fix for clarity
-- [ ] `tests/docs.test.ts` proves ARCHITECTURE.md contains expected
- sections (overview, source layout, key modules).
+- [ ] `tests/docs.test.ts` proves ARCHITECTURE.md contains at minimum:
+ overview, source layout, and key modules sections.📝 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.
| - [ ] `tests/docs.test.ts` proves the required OSS files exist. | |
| - [ ] `tests/docs.test.ts` proves ARCHITECTURE.md contains expected | |
| sections (overview, source layout, key modules). | |
| - [ ] `tests/docs.test.ts` proves the required OSS files exist. | |
| - [ ] `tests/docs.test.ts` proves ARCHITECTURE.md contains at minimum: | |
| overview, source layout, and key modules sections. |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/design/0026-oss-release-scaffolding/oss-release-scaffolding.md` around
lines 34 - 36, The acceptance criteria for ARCHITECTURE.md are ambiguous; update
the doc and tests/docs.test.ts to make the requirement binary: either (A)
enumerate an exhaustive list of required sections (e.g., "Overview", "Source
layout", "Key modules", "Dependencies", "Deployment", etc.) and change the line
to "ARCHITECTURE.md MUST contain the following sections: <list>", or (B) state
these three are the minimum required and add "At minimum, ARCHITECTURE.md MUST
contain: Overview, Source layout, Key modules" and allow additional sections;
then adjust tests/docs.test.ts to assert the exact behavior you choose (check
for the exhaustive list if you pick A, or check only for the three minimum
headers if you pick B).
| ## Non-goals | ||
|
|
||
| - [ ] Comprehensive API reference (JSDoc/typedoc level). | ||
| - [ ] Tutorial or getting-started guide (that's a separate cycle). |
There was a problem hiding this comment.
Checkboxes in Non-goals section create semantic confusion.
Lines 53-54 format non-goals as checkboxes. What does checking or unchecking a non-goal checkbox mean? The README.md template (lines 262-271) shows "Non-goals" as a section without checkbox formatting. Use prose bullets or explicitly define the checkbox semantics for non-goals.
📝 Proposed fix to remove checkbox ambiguity
## Non-goals
-- [ ] Comprehensive API reference (JSDoc/typedoc level).
-- [ ] Tutorial or getting-started guide (that's a separate cycle).
+- Comprehensive API reference (JSDoc/typedoc level).
+- Tutorial or getting-started guide (that's a separate cycle).📝 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.
| ## Non-goals | |
| - [ ] Comprehensive API reference (JSDoc/typedoc level). | |
| - [ ] Tutorial or getting-started guide (that's a separate cycle). | |
| ## Non-goals | |
| - Comprehensive API reference (JSDoc/typedoc level). | |
| - Tutorial or getting-started guide (that's a separate cycle). |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/design/0026-oss-release-scaffolding/oss-release-scaffolding.md` around
lines 51 - 54, The "Non-goals" section currently uses checkbox markdown which
creates semantic confusion; update the "Non-goals" under the "Non-goals" header
to use plain bullet points (e.g., "- Comprehensive API reference (JSDoc/typedoc
level)." and "- Tutorial or getting-started guide (that's a separate cycle).")
to match the README.md template's non-checkbox format, or alternatively add a
single sentence explicitly defining the checkbox semantics for non-goals if you
prefer to keep checkboxes; edit the "Non-goals" header and its two items
accordingly to remove ambiguity.
|
|
||
| ## Test Results | ||
|
|
||
| ``` |
There was a problem hiding this comment.
Add fence languages to satisfy markdownlint.
Both fenced blocks are untyped, which triggers MD040 and can fail strict docs linting.
Suggested patch
-```
+```text
> method@0.2.0 test
> vitest run --config vitest.config.ts
@@
-```
+```
@@
-```
+```text
Playback-question drift found.
Scanned 1 active cycle, 7 playback questions, 135 test descriptions.
@@
-```
+```Also applies to: 28-28
🧰 Tools
🪛 markdownlint-cli2 (0.22.0)
[warning] 12-12: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/method/retro/0026-oss-release-scaffolding/witness/verification.md` at
line 12, Two fenced code blocks are untyped which triggers markdownlint MD040;
update each untyped triple-backtick fence that contains the lines starting with
"method@0.2.0 test" and the block starting with "Playback-question drift found."
to include a language tag (e.g., use ```text) so both blocks read as fenced with
a language and satisfy the linter.
| | `method drift [cycle]` | Check active cycle playback questions against test descriptions. | | ||
| | `method status` | Summarize backlog lanes, active cycles, and legend load. | | ||
| | `method mcp` | Start the MCP server over stdio. | | ||
| | `method sync github [--push] [--pull]` | Sync backlog with GitHub Issues. | |
There was a problem hiding this comment.
Inconsistent GitHub capitalization.
Line 462 uses lowercase "github" in the command method sync github. While the command itself may use lowercase, the Purpose column should maintain proper capitalization: "Sync backlog with GitHub Issues" (which you already do correctly). However, consider whether the command name display should reflect the proper brand capitalization for clarity.
As per static analysis hints, the official platform name is "GitHub" with a capital H.
📝 Proposed fix for brand consistency
If you want to clarify that the command uses lowercase while referencing the proper brand:
-| `method sync github [--push] [--pull]` | Sync backlog with GitHub Issues. |
+| `method sync github [--push] [--pull]` | Sync backlog with GitHub Issues. (command uses lowercase) |Or update command table header to indicate command syntax vs brand names are different things.
📝 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.
| | `method sync github [--push] [--pull]` | Sync backlog with GitHub Issues. | | |
| | `method sync github [--push] [--pull]` | Sync backlog with GitHub Issues. (command uses lowercase) | |
🧰 Tools
🪛 LanguageTool
[uncategorized] ~462-~462: The official name of this software platform is spelled with a capital “H”.
Context: ... | Start the MCP server over stdio. | | method sync github [--push] [--pull] | Sync backlog with ...
(GITHUB)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@README.md` at line 462, Update the README table row so the command cell
clearly indicates the actual lowercase CLI token while the Purpose cell keeps
the branded capitalization: leave the command display as `method sync github`
but append a short parenthetical like "(command uses lowercase 'github')" next
to it, and ensure the Purpose remains "Sync backlog with GitHub Issues"; update
the table header or add a brief note if you prefer to document syntax-vs-brand
rules consistently across the commands list.
| ### MCP Tools | ||
|
|
||
| The MCP server exposes METHOD operations for agent integration. Every | ||
| tool requires a `workspace` parameter (absolute path to the workspace |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Minor wording mismatch with implementation.
Line 468 describes the workspace parameter as "absolute path to the workspace root" but src/mcp.ts:1 defines it more precisely as "Absolute path to the METHOD workspace root directory". Consider using the exact wording from the implementation for consistency.
♻️ Proposed alignment with src/mcp.ts
-tool requires a `workspace` parameter (absolute path to the workspace
-root). See `ARCHITECTURE.md` for the full tool reference.
+tool requires a `workspace` parameter (absolute path to the METHOD
+workspace root directory). See `ARCHITECTURE.md` for the full tool reference.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@README.md` at line 468, Update the README's description for the workspace
parameter to match the implementation: replace "absolute path to the workspace
root" with the exact phrasing used by the implementation for the workspace
parameter—"Absolute path to the METHOD workspace root directory"—so the README's
`workspace` parameter text matches the definition in mcp.ts.
| | Tool | Purpose | | ||
| |------|---------| | ||
| | `method_status` | Get workspace status as JSON. | | ||
| | `method_inbox` | Capture an idea into the inbox. | | ||
| | `method_pull` | Promote a backlog item into a cycle. | | ||
| | `method_drift` | Check playback-question drift. | | ||
| | `method_close` | Close a cycle with retro and witness. | | ||
| | `method_sync_ship` | Perform ship sync. | | ||
| | `method_sync_github` | Sync backlog with GitHub Issues. | | ||
| | `method_capture_witness` | Capture verification witness. | |
There was a problem hiding this comment.
MCP tool descriptions are imprecise and lose critical implementation details.
Comparing the table to src/mcp.ts:1-120:
-
Line 473 (
method_status): Says "Get workspace status as JSON" but the implementation describes richer output: "backlog lanes, active cycles, legend health". The JSON format is an implementation detail, not the semantic purpose. -
Line 475 (
method_pull): Says "Promote a backlog item into a cycle" but implementation specifies "into the next numbered cycle" - the sequencing is important. -
Line 476 (
method_drift): Says "Check playback-question drift" but implementation says "Check active cycle playback questions against tests" - the verification mechanism matters. -
Line 478 (
method_sync_ship): Says "Perform ship sync" but implementation provides critical detail: "update CHANGELOG.md and BEARING.md". Users need to know what ship sync actually does. -
Line 480 (
method_capture_witness): Says "Capture verification witness" but implementation says "Automate terminal evidence capture for a cycle" - these are semantically different concepts.
🔧 Proposed fixes to restore precision
| Tool | Purpose |
|------|---------|
-| `method_status` | Get workspace status as JSON. |
+| `method_status` | Get workspace status (backlog lanes, active cycles, legend health). |
| `method_inbox` | Capture an idea into the inbox. |
-| `method_pull` | Promote a backlog item into a cycle. |
+| `method_pull` | Promote a backlog item into the next numbered cycle. |
-| `method_drift` | Check playback-question drift. |
+| `method_drift` | Check active cycle playback questions against tests. |
| `method_close` | Close a cycle with retro and witness. |
-| `method_sync_ship` | Perform ship sync. |
+| `method_sync_ship` | Update CHANGELOG.md and BEARING.md (ship sync). |
-| `method_sync_github` | Sync backlog with GitHub Issues. |
+| `method_sync_github` | Synchronize backlog with GitHub Issues. |
-| `method_capture_witness` | Capture verification witness. |
+| `method_capture_witness` | Automate terminal evidence capture for a cycle. |📝 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.
| | Tool | Purpose | | |
| |------|---------| | |
| | `method_status` | Get workspace status as JSON. | | |
| | `method_inbox` | Capture an idea into the inbox. | | |
| | `method_pull` | Promote a backlog item into a cycle. | | |
| | `method_drift` | Check playback-question drift. | | |
| | `method_close` | Close a cycle with retro and witness. | | |
| | `method_sync_ship` | Perform ship sync. | | |
| | `method_sync_github` | Sync backlog with GitHub Issues. | | |
| | `method_capture_witness` | Capture verification witness. | | |
| | Tool | Purpose | | |
| |------|---------| | |
| | `method_status` | Get workspace status (backlog lanes, active cycles, legend health). | | |
| | `method_inbox` | Capture an idea into the inbox. | | |
| | `method_pull` | Promote a backlog item into the next numbered cycle. | | |
| | `method_drift` | Check active cycle playback questions against tests. | | |
| | `method_close` | Close a cycle with retro and witness. | | |
| | `method_sync_ship` | Update CHANGELOG.md and BEARING.md (ship sync). | | |
| | `method_sync_github` | Synchronize backlog with GitHub Issues. | | |
| | `method_capture_witness` | Automate terminal evidence capture for a cycle. | |
🧰 Tools
🪛 LanguageTool
[uncategorized] ~479-~479: The official name of this software platform is spelled with a capital “H”.
Context: ...hod_sync_ship| Perform ship sync. | |method_sync_github` | Sync backlog with GitHub Issues. | |...
(GITHUB)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@README.md` around lines 471 - 480, The MCP tool table entries are too
vague—update each row to match the implementations in src/mcp.ts: replace
method_status with a description like "Return workspace state (backlog lanes,
active cycles, legend health) as structured JSON"; change method_pull to
"Promote a backlog item into the next numbered cycle"; change method_drift to
"Check active cycle playback questions against tests to detect drift"; change
method_sync_ship to "Perform ship sync and update CHANGELOG.md and BEARING.md";
and change method_capture_witness to "Automate terminal evidence capture for a
cycle (verification witness)"; ensure each tool name (method_status,
method_pull, method_drift, method_sync_ship, method_capture_witness) is
referenced exactly as in src/mcp.ts so the README matches the code.
| METHOD uses OS-native keychains for secrets management via | ||
| `@git-stunts/vault` when available. GitHub tokens in `.method.json` | ||
| should be treated as sensitive — ensure `.method.json` is in | ||
| `.gitignore` if it contains credentials. |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== Verify whether vault/keychain integration exists =="
rg -n -C2 '@git-stunts/vault|keychain|credential store|secret store' SECURITY.md package.json src
echo
echo "== Verify implemented token sources =="
rg -n -C3 'GITHUB_TOKEN|github_token|\\.method\\.json' src/config.ts
echo
echo "== Verify token handling in GitHub adapter =="
rg -n -C3 'private readonly token|Authorization: `Bearer \\$\\{this\\.token\\}`' src/adapters/github.tsRepository: flyingrobots/method
Length of output: 1325
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== Check if `@git-stunts/vault` is in dependencies =="
rg -n '@git-stunts/vault' package.json package-lock.json 2>/dev/null || echo "Not found in package.json/lock"
echo
echo "== Search for vault-related imports or usage in src =="
rg -n 'vault|Vault' src/ 2>/dev/null || echo "No vault references in src/"
echo
echo "== Check GitHub adapter token handling (direct search) =="
rg -n 'Authorization.*Bearer|private.*token|this\.token' src/adapters/github.ts || echo "Pattern not found"
echo
echo "== Show GitHub adapter implementation =="
head -50 src/adapters/github.tsRepository: flyingrobots/method
Length of output: 1645
SECURITY.md falsely claims a nonexistent secret-management capability that doesn't exist anywhere in this codebase.
Lines 27-29 claim keychain support via @git-stunts/vault, but verification reveals:
@git-stunts/vaultis not a dependency (absent from package.json/package-lock.json)- Zero vault/keychain code exists in src/
- GitHub adapter stores tokens directly as private properties and passes them as plain Bearer tokens in Authorization headers
This is a documentation-reality mismatch with security posture implications—users may trust a non-existent security mechanism. Update the documentation to reflect the actual implementation.
Suggested correction
- METHOD uses OS-native keychains for secrets management via
- `@git-stunts/vault` when available. GitHub tokens in `.method.json`
- should be treated as sensitive — ensure `.method.json` is in
- `.gitignore` if it contains credentials.
+ METHOD reads GitHub credentials from `.method.json` and environment
+ variables (GITHUB_TOKEN). Tokens are handled as plain secrets and NOT
+ encrypted. Treat `.method.json` as sensitive and ensure it is in
+ `.gitignore` when credentials are present.📝 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.
| METHOD uses OS-native keychains for secrets management via | |
| `@git-stunts/vault` when available. GitHub tokens in `.method.json` | |
| should be treated as sensitive — ensure `.method.json` is in | |
| `.gitignore` if it contains credentials. | |
| METHOD reads GitHub credentials from `.method.json` and environment | |
| variables (GITHUB_TOKEN). Tokens are handled as plain secrets and NOT | |
| encrypted. Treat `.method.json` as sensitive and ensure it is in | |
| `.gitignore` when credentials are present. |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@SECURITY.md` around lines 27 - 30, Remove the false claim about OS-native
keychain support via `@git-stunts/vault` from SECURITY.md and replace it with an
accurate statement that no keychain/vault integration exists in the codebase (no
`@git-stunts/vault` dependency and no vault code in src/), explicitly note that
the GitHub adapter stores tokens as private properties and sends them as Bearer
tokens, and instruct users to treat `.method.json` as sensitive (add it to
`.gitignore` if it contains credentials) and to use an external OS keychain or
secrets manager if they need true secret storage.
1 participant
Summary
Adds standard GitHub community files and reference docs for the v0.3.0 release:
method mcp,sync github,sync shipto command table; added MCP tools sectionTest plan