module-governance

原文涵盖的主题

• Module Governance
• When to Activate
• How It Works
• 1. Discover the boundary before creating documents
• 2. Separate project-wide rules from local rules
• 3. Reuse the existing knowledge owners
• 4. Maintain only the authorized records
• 5. Verify both meaning and links

Connect module-level working rules to existing domain language, contracts, and decisions. This is an orchestration skill, not a second DDD methodology or an automatic documentation generator. The user asks to implement a new business module, without needing to name this skill. The user asks to document an existing module or maintain a confirmed responsibility change. An authorized module change needs local instructions and canonical knowledge pointers. Do not start setup for an ordinary bug, styling change, internal refactor with unchanged boundaries, or a new directory/UI component that simply inherits parent conventions. For design discussion or an audit alone, inspect and report without creating files. Intent-based selection is not a background hook and does not grant permission for unrelated code, commits, pushes, or business choices. Read applicable project and ancestor harness instructions, the existing map, requirements, relevant code, and contracts. Identify the module's responsibilities, non-responsibilities, state ownership, and actual consumers. Directory names alone do not establish a bounded context. Surface material ambiguities instead of inventing business rules. For

这里只展示节选，请以完整原文和当前要求为准。