supporting-modules-architecture

Support Module Architecture

Applicable Scenarios

• Determine whether a requirement belongs to Ticket, Environment, Notify, Log, Quality, or OpenAPI
• Understand the boundaries between support modules and core business modules
• Choose the correct module entry point for supporting requirements
• Troubleshoot responsibility attribution when core modules call support services

Inapplicable Scenarios

• Directly modifying the Process main chain
• Directly modifying core platform modules such as Auth, Dispatch, Worker, Agent, etc.
• Only handling the detailed implementation of a certain support module, but the module attribution is already clear

Quick Guide

1. This skill is mainly a "module router", helping determine which module a supporting capability should fall into.
2. Support modules usually provide credential, environment, notification, log, quality, and open interface capabilities, but they are not responsible for main pipeline orchestration.
3. First enter the existing reference documentation by capability:
   • Ticket：reference/1-ticket-module.md
   • Environment：reference/2-environment-module.md
   • Notify：reference/3-notify-module.md
   • Log：reference/4-log-module.md
   • Quality：reference/5-quality-module.md
   • OpenAPI：reference/6-openapi-module.md
4. If the problem clearly belongs to the pipeline main chain, switch to process-module-architecture。
5. If the problem involves core platform modules such as permissions, scheduling, execution, or artifacts, you should also switch to the corresponding module skill first.

High-Signal Rules

• Support modules are more like a capability foundation, called by core modules rather than leading the execution chain
• First determine whether the requirement is "part of the business main chain" or "a supporting capability reused by multiple modules"
• The common misconception with such modules is not implementation difficulty, but incorrect attribution judgment
• Boundaries are more important than details; choose the right module first, then drill down

Key Pitfalls

• Mistakenly attributing core process problems to support modules
• Because multiple modules call it, mistakenly assuming it belongs to Process or Auth
• Directly diving into the implementation of a submodule before the module boundary is clear

Further Reading

• Ticket：reference/1-ticket-module.md
• Environment：reference/2-environment-module.md
• Notify：reference/3-notify-module.md
• Log：reference/4-log-module.md
• Quality：reference/5-quality-module.md
• OpenAPI：reference/6-openapi-module.md
• If you need to look at the core pipeline chain: see also process-module-architecture
• If you need to look at global module collaboration: see also 00-bkci-global-architecture