docs: add postgresql enterprise connector scope

docs/superpowers/specs/2026-08-19-enterprise-connector-metadata-boundary-design.md

@@ -8,7 +8,7 @@ Approved design option: move database connector operations to Data Factory and i
 
 The current `企业连接器` page is owned by `数据研发`, but it combines two different responsibilities:
 
-- database connector compatibility and collection runtime operations for Oracle and SQL Server;
+- database connector compatibility and collection runtime operations for Oracle, PostgreSQL, and SQL Server;
 - controlled REST Catalog ingestion for importing metadata from an external catalog API.
 
 The database connector runtime belongs with production pipelines, observability, and connection-pool operations in `数据工厂`. REST Catalog is not a general enterprise data connector: it imports governed metadata from a fixed HTTPS catalog contract and belongs with metadata governance.
@@ -47,6 +47,7 @@ Existing route names and paths for the other entries remain unchanged.
 The user-facing Enterprise Connector page displays only these current database connectors:
 
 - Oracle Database;
+- PostgreSQL;
 - Microsoft SQL Server.
 
 The page filters both manifests and run records to the database connector allowlist. It must not display REST Catalog manifests or runs.
@@ -55,9 +56,11 @@ Add a visible scope notice:
 
 > 当前开放范围仅限数据库访问。文件目录、对象存储、API 与消息系统等来源将在后续版本扩展开发。
 
-The existing enterprise-UAT notice remains accurate: Oracle and SQL Server have engineering compatibility evidence, while real enterprise accounts, versions, networks, and UAT are still external prerequisites.
+The existing enterprise-UAT notice remains accurate: database connectors have local engineering compatibility evidence, while real enterprise accounts, versions, networks, and UAT are still external prerequisites.
 
-This change does not claim that PostgreSQL and MySQL have versioned enterprise connector implementations. They remain data-source and connection-pool capabilities until separate connector manifests are delivered.
+PostgreSQL is delivered as a real versioned enterprise connector rather than a presentation-only card. It reuses the existing PostgreSQL data-source manager and connection pool, executes read-only catalog SQL, and implements the same governed `discover`, `snapshot`, `incremental`, `cancel`, `resume`, and `evidence` contract as the other database connectors.
+
+MySQL remains a data-source and connection-pool capability. It is not shown as an enterprise connector until a separate versioned connector manifest and collection contract are delivered.
 
 ### 3. Integrate REST Catalog into Metadata Governance
 
@@ -74,7 +77,7 @@ The new external-catalog tab is implemented as a dedicated component under the m
 - REST Catalog run records;
 - checkpoint, cursor, attempt, error, cancel, and resume information.
 
-It must not display Oracle or SQL Server connector manifests or runs.
+It must not display Oracle, PostgreSQL, or SQL Server connector manifests or runs.
 
 The backend `rest-catalog` implementation, registry, runtime, persistence, API paths, and security controls remain unchanged. This is a frontend information-architecture split, not a duplicate backend implementation.
 
@@ -82,7 +85,7 @@ The backend `rest-catalog` implementation, registry, runtime, persistence, API p
 
 Extract the shared connector catalogue and run-table behavior from the existing page into one reusable frontend component. Page wrappers provide an explicit connector allowlist:
 
-- Enterprise Connectors: `oracle`, `sqlserver`;
+- Enterprise Connectors: `oracle`, `postgresql`, `sqlserver`;
 - Metadata external-catalog tab: `rest-catalog`.
 
 The shared component continues to use the existing datasource connector APIs. It filters manifests and runs before rendering. Page-specific notices and REST-only configuration fields remain in the appropriate wrapper or mode so that database users are not shown REST URL fields.
@@ -105,7 +108,7 @@ This separation avoids copying run, checkpoint, cancel, resume, and permission b
 
 ```text
 Data Factory → Enterprise Connectors
-    → database connector manifest
+    → Oracle, PostgreSQL, or SQL Server connector manifest
     → source_uid / approved credential reference
     → database connection manager and pool
     → discover, snapshot, or incremental metadata result
@@ -154,20 +157,21 @@ Rejected because the existing connector runtime already supplies the required se
 1. Add a failing navigation contract proving `enterpriseConnectors` exists exactly once under Data Factory and is absent from Data Research.
 2. Prove its path, name, component, permission, and direct-link compatibility are unchanged.
 3. Prove Data Factory ordering is stable and legacy n8n entries remain independently removable.
-4. Add component contracts proving the database surface renders only Oracle and SQL Server manifests and runs.
-5. Add component contracts proving the REST Catalog surface renders only `rest-catalog` manifests and runs.
-6. Prove the Metadata page contains exactly the `元数据管理` and `外部目录接入` tabs while preserving existing metadata CRUD behavior.
-7. Prove permission behavior for `connectors:read`, `connectors:operate`, and `connectors:manage`, including a metadata-only user who cannot load connector data.
-8. Run existing WP03 connector, metadata, RBAC, Data Factory navigation, and architecture contracts.
-9. Build the frontend production bundle.
-10. Rebuild the local UAT frontend and verify menu ownership, tab rendering, preserved direct links, and refresh behavior in an authenticated browser session.
+4. Add a PostgreSQL connector contract covering manifest registration, read-only catalog projection, scope filtering, snapshot/checkpoint evidence, cancellation, resume, and secret-free output.
+5. Add component contracts proving the database surface renders only Oracle, PostgreSQL, and SQL Server manifests and runs.
+6. Add component contracts proving the REST Catalog surface renders only `rest-catalog` manifests and runs.
+7. Prove the Metadata page contains exactly the `元数据管理` and `外部目录接入` tabs while preserving existing metadata CRUD behavior.
+8. Prove permission behavior for `connectors:read`, `connectors:operate`, and `connectors:manage`, including a metadata-only user who cannot load connector data.
+9. Run existing WP03 connector, data-source, connection-pool, metadata, RBAC, Data Factory navigation, and architecture contracts.
+10. Build the frontend production bundle.
+11. Rebuild the local UAT frontend and verify menu ownership, tab rendering, preserved direct links, PostgreSQL visibility, and refresh behavior in an authenticated browser session.
 
 ## Rollback
 
-Rollback is frontend-only:
+Rollback of the information-architecture split is frontend-only:
 
 - move the unchanged `enterpriseConnectors` navigation object back to Data Research;
 - restore the combined page rendering;
 - remove the Metadata external-catalog tab and shared wrapper.
 
-No connector facts, data-source definitions, credentials, runs, checkpoints, metadata assets, database migrations, or backend API contracts are changed by this navigation split.
+The PostgreSQL connector is an additive registry implementation with no database migration or new API path. Its rollback removes the PostgreSQL manifest registration and implementation after confirming no run depends on that connector/version. No data-source definitions, credentials, metadata assets, database migrations, or backend API contracts are changed by the navigation split.