Integrate main_for_Merge: docs alignment, coding disciplines, Antigravity hardening, setup fixes

[kazumori102]

Summary

Brings main_for_Merge (9 commits, fast-forward over main) up to main.
No history divergence — clean fast-forward.

Docs

• Correct project management wording (DIV-001 / DIV-004 / DIV-005) to match
  the actual implementation.

Infra / behavior

• Coding disciplines C001 / C002 added; dashboard fix.
• Antigravity CLI hardening (regenerated instructions/generated/*,
  lib/cli_adapter.sh).
• Detect Codex MCP init failures after departure launch.

Setup robustness

• Grant exec bits via sudo in first_setup.sh STEP 9.
• Keep inbox symlink target alive across setup re-runs.
• Use a relative path for the Stop hook in .claude/settings.json.

Notes

• queue/ and local-only proposal drafts are git-ignored and not included.

🤖 Generated with Claude Code

[kazumori102]

Project Management Structure: Proposal for Upstream Review

Context / Background

• This system is a tmux-based multi-agent development platform that orchestrates multiple AI coding CLIs (Claude Code, Codex, Copilot, Kimi, OpenCode, Cursor, and Antigravity) with a documented project management structure.
• In cmd_010, Gunshi reviewed the gap between the documented structure and the actual implementation.
• The overall finding was that parts of the project management design are documented as if they are implemented features, while the current system mainly works through agent instructions and conventions.

Already-Resolved Items

• DIV-001, DIV-004, and DIV-005 were already fixed in commit 201ce2e using Option A: scaling down the documentation to match the current implementation.
• If upstream chooses full Option B for the project management structure, those changes would need to be revisited so the documentation and implementation move together.

DIV-002: projects/{id}.yaml

What the Docs Say

• README.md L558 describes projects/{id}.yaml plus context/{id}.md as the unit equivalent to a Visual Studio solution.
• README.md L1744-L1750 describes projects/<id>.yaml as the place for full project details, including client information, contracts, Notion pages, and tasks.
• The same section states that projects/ is excluded from git because it contains confidential information.
• CLAUDE.md L16 and L210 describe this file as project details that are git-ignored and may contain secrets.

Actual State

• The projects/ directory does not exist, not even as an empty directory.
• The only instruction reference found was shogun.md L291, which is an ambiguous input-search reference.
• No scripts or library code read from projects/{id}.yaml.
• There is zero runtime enforcement for this structure.

Impact

• Medium.
• The documentation implies a core project-management feature, but the current implementation is an absent, optional convention.

Option A: Scale Down the Docs

• Describe projects/ as an optional convention for private deployments.
• Acknowledge that the system works without projects/{id}.yaml.
• Clarify that context/ currently carries project knowledge in practice.
• This would align the documentation with the current lightweight, instruction-driven implementation.

Option B: Implement the Documented Behavior

• Keep the current aspirational documentation.
• Add a script or agent mechanism that reads projects/{id}.yaml at runtime.
• Make the documented behavior real through loader logic, validation, or task-resolution support.
• This would turn projects/{id}.yaml from a convention into an implemented project-detail layer.

My Recommendation

• I recommends Option B.
• The README describes projects/{id}.yaml as an intended project-management layer, including confidential project details and operational metadata.
• If that is the intended design, implementing the loader is preferable to walking back the architecture, because it preserves the documented two-layer model and makes the system behavior match the maintainer-facing design.

Question for Upstream

• Was projects/{id}.yaml intended as a core implemented feature, or as an optional convention for users to adopt if they wish?

DIV-003: context/{project}.md Naming and Loading

What the Docs Say

• README.md L590 says that when the Shogun issues a command related to a project, it automatically references context/{name}.md.
• README.md and CLAUDE.md describe context files as following a {project}.md naming pattern that matches project IDs in config/projects.yaml.
• session_start_hook.sh L75 instructs agents to read context/{project}.md.

Actual State

• context/ contains README.md, which documents the directory.
• context/ also contains servy-glossary.md, a glossary for the Servy translation project from cmd_005.
• Neither file follows a {project}.md convention matching a project ID.
• The mechanism is instruction-driven: agents are told to read the context file.
• There is no programmatic auto-reference mechanism.
• If context is cleared, the reference only restores if agents re-read their instructions.

Impact

• Medium.
• The phrase "automatically references" implies a programmatic mechanism that does not exist.
• The naming convention is documented, but it is not enforced and the existing files do not follow it.

Option A: Acknowledge Flexible Naming

• Document context/ as a free-form knowledge store.
• Treat {project}.md as a suggested pattern rather than an enforced convention.
• Keep existing files such as README.md and servy-glossary.md as they are.
• Clarify that agents read context through instructions, not through automatic runtime loading.

Option B: Standardize and Enforce the Convention

• Implement the {project}.md convention with tooling or validation.
• Align existing files with the project ID system, for example by renaming servy-glossary.md to context/servy.md and adding servy to config/projects.yaml.
• Replace "automatically references" with an accurate description of the instruction-driven mechanism unless true automatic loading is implemented.
• This would make project context naming predictable and auditable.

My Recommendation

• I recommends Option B.
• The documentation currently presents context/{project}.md as part of the project-management structure, not merely an ad-hoc knowledge folder.
• Standardizing the convention would make project context easier to discover, easier to validate, and consistent with the project IDs in config/projects.yaml.

Question for Upstream

• Was context/{project}.md intended as a strict convention with tooling enforcement, or as a flexible guideline?

Closing

We welcome upstream guidance on the intended design for both items. We will implement based on your direction.