repository-module-architecture

Repository module architecture

Applicable scenarios

Integrating or managing repositories
Handling repository authentication, OAuth, SSH, Token
Configuring or troubleshooting Webhook
Handling PAC repositories and commit records
Determining which service implementation a certain repository type should fall under

It is only a general Git command usage issue
It is only a PAC YAML conversion issue and does not involve repository integration
It is only a permission model definition and does not involve the repository resource itself

First determine which main line the issue belongs to:
- Repository basics and type differences: see reference/1-repository-foundation.md
- Webhook, PAC, authentication, and troubleshooting: see reference/2-webhook-pac-auth.md
The core of the Repository module is not "executing Git operations", but "managing repository resources, authentication methods, Webhook, and platform integration semantics".
As long as repository types, authentication logic, or PAC switches are changed, you must simultaneously look at the repository detail table, authentication methods, and Webhook behavior.
If a PAC issue has already entered the YAML parsing or template expansion layer, then switch to yaml-pipeline-transfer。

Repository is responsible for repository resource integration and management, not for the pipeline model itself
Different repository types are not completely consistent in authentication, fields, and API capabilities
PROJECT_ID should still be understood by the project English identifier
PAC is a repository-side switch and context source, and is not equal to the YAML conversion implementation itself

Treating repository type differences as one unified logic and handling them rigidly
Only looking at the main table and not looking at the detail tables of each repository type
Misjudging a Webhook issue as a repository save issue, or vice versa
Assuming that once the PAC switch is on, all YAML / triggers will work by default