chore: finalize integrated release baseline

.project-docs/10-decisions/AUTH-001-fixed-scope-account-authorization.md

@@ -2,7 +2,7 @@
 
 ## Status
 
-Accepted; superseded in part by AUTH-002
+Accepted; superseded in part by AUTH-002 and AUTH-004
 
 ## Date
 
@@ -10,7 +10,7 @@ Accepted; superseded in part by AUTH-002
 
 ## Supersession Note
 
-AUTH-002 supersedes only this ADR's organization-wide ERP FIFO and archive-only removal clauses. The remaining fixed-scope account, role, route-grant, owner-isolation, dashboard, AgentBus assignment, browser-worker, and ERP-identity decisions remain active. Current execution-queue and deletion behavior must be read from AUTH-002.
+AUTH-002 supersedes this ADR's organization-wide ERP FIFO and archive-only removal clauses. AUTH-004 additionally supersedes administrator task creation, all-route possession, task-wide reads, dashboard access, task transitions, and force-delete authority, plus the manual-task-only leadership-dashboard scope. The remaining fixed-scope account, employee route-grant, owner-isolation, AgentBus assignment, browser-worker, and ERP-identity decisions remain active. Current execution-queue and employee deletion behavior must be read from AUTH-002; current administrator and dashboard boundaries must be read from AUTH-004.
 
 ## Context
 
@@ -20,16 +20,16 @@ The platform already required login but treated the fixed deployment scope as a
 
 - Keep one internal `organization_id` deployment scope and do not expose organization selection or tenant administration.
 - Use three roles: `admin`, `team_lead`, and `user`.
-- Administrators manage account lifecycle, passwords, sessions, global settings/audit, AgentBus channels, and all manual/AgentBus task visibility. They always hold all 18 registered manual business routes, but their inspection authority does not grant ERP execution authority over work assigned to another account.
+- Superseded by AUTH-004 for task access: administrators manage account lifecycle, passwords, sessions, global settings/audit, AgentBus channels, parser routing, and employee grants, but hold no business routes and do not enter the task data plane.
 - Password entry points require a non-empty value but impose no application-level minimum or maximum length. The platform does not force a password change on first login or after an administrator reset; voluntary self-service change, administrator reset, and session revocation remain supported. The historical `must_change_password` column is compatibility-only and is cleared on password writes.
-- Team leads and ordinary users use normal business APIs only for their own manual tasks. New non-administrator accounts start with no task-type grants and may invoke only routes explicitly granted by an administrator.
+- Team leads and ordinary users use normal business APIs only for tasks assigned to themselves, whether created manually or through AgentBus. New non-administrator accounts start with no task-type grants and may invoke only routes explicitly granted by an administrator.
 - Re-read route authorization before intake and relevant task state transitions. Known denied routes and unknown/non-unique routes fail closed before parsing, plugin dispatch, or ERP execution.
-- Give team leads a dedicated read-only platform-operations dashboard over all manual account tasks. It is an aggregate-first leadership view across task, person, original input, final output, time, task type, and completion state; every aggregate may drill into the same bounded business-facing task projection.
+- Superseded in scope by AUTH-004: give team leads a dedicated read-only platform-operations dashboard over every durably assigned manual and AgentBus task, using immutable assignment as the employee dimension. Administrators do not access this dashboard.
 - Keep the leadership dashboard separate from audit and engineering diagnostics. It never renders parser/executor payloads, internal identifiers, codes, machine-shaped historical input, or technical failure text; those values are replaced by a concise business explanation without changing the underlying audit evidence.
 - Keep leadership summary cards display-only. Status changes are explicit filter-form actions, default to all results, and retain the business-facing merge of internal attention states into “进行中”.
 - Superseded by AUTH-002 for removal behavior: preserve creator and input-turn attribution with encrypted input at rest. The original decision exposed archive/restore only and did not expose irreversible purge.
 - Bind each enabled AgentBus channel to exactly one active `user` or `team_lead` account with a configured, case-insensitively unique expected ERP account. Administrator accounts remain unbound from employee channels.
-- Execute inbound AgentBus work under the bound employee identity and that account's route allowlist. Persist one immutable task assignee for both manual and AgentBus work; confirmation, browser claim/result, reconciliation, and resume require the assignee even when the caller is an administrator.
+- Execute inbound AgentBus work under the bound employee identity and that account's route allowlist. Persist one immutable task assignee for both manual and AgentBus work; confirmation, browser claim/result, reconciliation, and resume require that employee assignee. Administrators cannot invoke those transitions.
 - Allow only one fresh browser execution worker per account. Heartbeats must match the account's expected ERP identity; a second fresh worker or mismatched ERP session fails closed, and automatic failover begins only after the prior worker is stale.
 - Superseded by AUTH-002 for queue scope: the original decision preserved organization-wide ERP FIFO serialization. Employee worker binding chose who could execute but did not authorize parallel ERP writes.
 
@@ -40,9 +40,9 @@ This model fits a single-organization deployment while enforcing least privilege
 ## Consequences
 
 - Migrations 015–018 must be applied before the updated control plane starts.
-- Existing accounts migrate as administrators; newly created team leads and users require explicit task grants.
+- Existing accounts originally migrated as administrators; under AUTH-004, administrator identities are management-only and newly created team leads/users require explicit task grants.
 - Existing historical `must_change_password=true` values do not restrict login, reads, or mutations; no destructive migration is required to retire the forced-change flow.
-- Permission revocation can block an existing task at confirmation or browser claim even when an administrator attempts the transition.
+- Permission revocation can block an existing task at confirmation or browser claim; administrators cannot attempt either transition.
 - Existing unbound AgentBus channels and historical unassigned AgentBus tasks remain non-executable until an administrator completes an explicit employee binding; no assignee is inferred from whichever browser is online.
 - Extension `0.5.164` is the first release carrying the expected-ERP identity probe required by this worker contract.
 - Cross-user operational visibility is intentionally separated from normal task mutation and technical debugging surfaces.
@@ -52,6 +52,10 @@ This model fits a single-organization deployment while enforcing least privilege
 
 - The implicit administrator-only, organization-shared account behavior of the earlier control-plane baseline.
 
+## Revision
+
+- 2026-09-07: AUTH-004 removed administrators from the task data plane and expanded the team-lead dashboard from manual-origin work to all durably assigned manual and AgentBus tasks.
+
 ## Related
 
 - `control-plane/migrations/015_account_roles_and_task_audit.sql`
@@ -61,3 +65,4 @@ This model fits a single-organization deployment while enforcing least privilege
 - `.project-docs/30-worklog/tasks/20260901-account-system-impl-d4e7a2.md`
 - `.project-docs/30-worklog/tasks/20260901-leadership-dashboard-c4b9e1.md`
 - `.project-docs/30-worklog/tasks/20260902-integrate-all-push-c93a7f21.md`
+- `.project-docs/10-decisions/AUTH-004-admin-management-plane-and-leader-oversight.md`

.project-docs/10-decisions/AUTH-002-account-scoped-execution-and-force-delete.md

@@ -2,12 +2,16 @@
 
 ## Status
 
-Accepted
+Accepted; superseded in part by AUTH-004
 
 ## Date
 
 2026-09-03
 
+## Supersession Note
+
+AUTH-004 supersedes this ADR's administrator-wide task read model and administrator force-delete authority. Per-assignee FIFO, assignee-only executable routing, reversible archive/restore, and lifecycle-independent force delete remain active for the owning `team_lead` or `user` account.
+
 ## Context
 
 AUTH-001 bound each task to one employee account and one matching ERP browser worker, but retained organization-wide ERP FIFO and archive-only operator removal. In production, one blocked or stale account could therefore hold every other employee's work behind the same queue. Administrator-wide task visibility also shared paths with executable event delivery, allowing an administrator page and plugin to observe or attempt to process another employee's task. Finally, an active or waiting task could fail the archive gate and then could not be permanently removed, leaving the same blocked state in place.
@@ -19,9 +23,9 @@ The user explicitly required independent execution across accounts, FIFO only wi
 - Use immutable `tasks.assigned_user_id` as the ERP execution queue and routing partition.
 - Serialize browser claims with an advisory transaction lock scoped to organization plus assigned account. Active-execution checks, confirmed FIFO selection, and queue positions include only that account's tasks.
 - Preserve deterministic FIFO and at most one active ERP execution for one assigned account. A different assigned account's active, queued, stale, or uncertain task does not block this account and does not occupy its queue position.
-- Keep administrator-wide task visibility as a read model only. Executable SSE history/live events, browser claims, plugin-result ingestion, and browser cleanup commands are accepted or delivered only for the authenticated account matching the task's immutable assignee, including when the signed-in role is administrator.
+- Superseded by AUTH-004 for administrators: task reads and executable SSE, browser claims, plugin results, and cleanup commands are available only to a `team_lead` or `user` session matching the immutable assignee. Administrators have no task read model.
 - Keep archive and restore as the reversible routine workflow, with their existing lifecycle-state guard.
-- Expose separately confirmed force delete through the single-task and bulk-delete APIs. Force delete intentionally has no parse, handoff, queue, or ERP-execution status gate, while retaining organization and owner authorization.
+- Expose separately confirmed force delete through the single-task and bulk-delete APIs. Force delete intentionally has no parse, handoff, queue, or ERP-execution status gate, while requiring the owning employee account under AUTH-004.
 - On force delete, remove the task, task-owned records through existing cascades, and task outbox entries atomically. Retain only a minimal non-content `task.hard_deleted` audit marker, then request OSS artifact cleanup and owner-plugin local cancellation/cache cleanup after commit on a best-effort basis.
 - Force delete removes platform state only. It cannot roll back an ERP write that already happened, and the operator warning must state this explicitly.
 
@@ -33,10 +37,10 @@ The execution account is already the durable link between the platform user, Age
 
 - Two employees with distinct assigned accounts and valid matching workers may execute concurrently; tasks for either employee remain FIFO and single-active within that employee's queue.
 - An uncertain ERP result blocks only the same assigned account's later claims unless an authorized operator explicitly force-deletes the platform task or resolves it through the existing reconciliation workflow.
-- Administrators may inspect and force-delete authorized organization tasks, but their browser never receives or submits another employee's executable task events, plugin results, or cleanup command.
+- Superseded by AUTH-004: administrators may neither inspect nor force-delete business tasks. The owning employee session alone receives executable task events, plugin results, and cleanup commands.
 - A force-deleted task and its task-owned evidence cannot be restored. The retained audit marker proves the destructive action without retaining task content.
 - No database migration or Chrome extension source/version change is required. The control-plane and platform UI must be deployed together before relying on the behavior.
-- Runtime acceptance requires an authorized administrator-plus-two-employees staging matrix, including cross-account concurrency, same-account FIFO, administrator event isolation, and waiting/active force deletion.
+- Runtime acceptance requires separate management and employee sessions plus two employee workers, including cross-account concurrency, same-account FIFO, administrator task-API denial, and owner-performed waiting/active force deletion.
 
 ## Supersedes
 
@@ -45,6 +49,8 @@ The execution account is already the durable link between the platform user, Age
 
 All other AUTH-001 account, role, route-grant, ownership, dashboard, session, AgentBus, and expected-ERP-identity decisions remain active.
 
+AUTH-004 is the current authority for administrator task isolation and leadership-dashboard scope.
+
 ## Related
 
 - `.project-docs/10-decisions/AUTH-001-fixed-scope-account-authorization.md`
@@ -53,3 +59,4 @@ All other AUTH-001 account, role, route-grant, ownership, dashboard, session, Ag
 - `control-plane/src/task-service.ts`
 - `control-plane/src/server.ts`
 - `LianSyn-platform/app.js`
+- `.project-docs/10-decisions/AUTH-004-admin-management-plane-and-leader-oversight.md`

.project-docs/10-decisions/AUTH-004-admin-management-plane-and-leader-oversight.md

@@ -0,0 +1,56 @@
+# AUTH-004: Management-only administrators and assignee-based leader oversight
+
+## Status
+
+Accepted
+
+## Date
+
+2026-09-07
+
+## Context
+
+The fixed-scope account model previously let administrators create and inspect business tasks while withholding only employee ERP execution. This still placed administrator sessions, pages, and database principals inside the task data plane. Separately, the team-lead operations dashboard was restricted to manual tasks and used origin attribution, so assigned AgentBus work was absent from the leadership view.
+
+The user explicitly required administrators to be management-plane-only identities and required the group-leader dashboard to show every employee-assigned business task, regardless of manual or AgentBus intake.
+
+## Decision
+
+- Administrators manage accounts, roles, passwords, sessions, employee task-route grants, AgentBus channels, parser routing, automation settings, and audit. They cannot create, list, inspect, mutate, confirm, claim, reconcile, archive, restore, force-delete, stream, or submit results for business tasks.
+- Administrator sessions do not register browser workers, open task SSE, call the ERP extension bridge, receive task cleanup commands, own employee channels, hold business-route grants, or become leader-summary subscribers or recipients.
+- Only active `team_lead` and `user` identities enter the task data plane. Their normal task APIs, executable events, browser claims/results, reconciliation, archive/restore, and force delete remain restricted to immutable `assigned_user_id`.
+- The operations dashboard is available only to team leads. It is an organization-wide, read-only business projection over durably assigned `manual` and `agentbus` tasks. Employee rankings, person filters, search, pagination, and detail use immutable `assigned_user_id`; historical AgentBus rows without an assignee are excluded rather than inferred.
+- Dashboard visibility does not grant cross-user task mutation, executable events, artifacts, browser access, reconciliation, or ERP authority. AUTH-002 account-scoped queues and AUTH-003's separate privacy-bounded leader-summary outbox remain unchanged.
+- Migration `021_admin_task_data_plane_isolation` removes legacy administrator task assignments and executable bindings without deleting task history, then uses database constraints and role-promotion cleanup to prevent administrators from re-entering task-principal relationships.
+
+## Rationale
+
+Separating management identities from business-task identities eliminates accidental administrator assignment, execution, and data exposure at the server and database boundaries. Using immutable assignment for the team-lead read model makes manual and AgentBus work consistent without inventing ownership for historical rows or weakening employee execution isolation.
+
+## Consequences
+
+- Migrations through `021_admin_task_data_plane_isolation` must complete before the updated application starts.
+- Existing administrator-assigned tasks keep their historical task rows but lose executable assignment and leases. Administrator channels, browser workers, route grants, active summary subscriptions, and pending summary deliveries are disabled or removed.
+- Administrators are redirected to management pages and cannot use the task history or operations dashboard. Operational canaries require separate administrator and employee/team-lead sessions.
+- Team leads can inspect all assigned manual and AgentBus work through the bounded business-facing dashboard while normal task operations remain owner-only.
+- Production migration, deployment, restart, and role/device canaries remain separately authorized runtime work.
+
+## Supersedes
+
+- AUTH-001 clauses granting administrators all manual routes, manual task creation, organization-wide task visibility, dashboard access, or assignee task transitions.
+- AUTH-001's manual-task-only dashboard scope and origin-based employee attribution.
+- AUTH-002 clauses retaining administrator-wide task reads or administrator force-delete authority.
+
+AUTH-002's per-assignee execution queues and employee force-delete semantics remain active. AUTH-003 remains active without change.
+
+## Related
+
+- `.project-docs/10-decisions/AUTH-001-fixed-scope-account-authorization.md`
+- `.project-docs/10-decisions/AUTH-002-account-scoped-execution-and-force-delete.md`
+- `.project-docs/10-decisions/AUTH-003-leader-task-summary-notifications.md`
+- Feature commit `9043ad6eda0deb2a620e1303467d1c3bd80374ed`
+- Feature commit `a2378c8`
+- `control-plane/migrations/021_admin_task_data_plane_isolation.sql`
+- `control-plane/src/task-service.ts`
+- `control-plane/src/server.ts`
+- `LianSyn-platform/app.js`

.project-docs/10-decisions/EXT-001-central-service-host-extension-updates.md

@@ -10,9 +10,9 @@ Reverted
 
 ## Reversal
 
-On 2026-09-03 the user explicitly directed that this iteration be backed up and its server-side automatic-update architecture removed from the main branch, then clarified that the Chrome plugin itself must remain at `0.5.167`. The exact full-stack state at commit `b2e33e2e5d29138891eabc93969cf24907492dfe` is preserved on remote branch `codex/backup-extension-update-20260903-b2e33e2`; active `main` keeps the exact `0.5.167` plugin source/package but restores the control plane to migration 018 with no private-OSS/ECS update orchestration.
+On 2026-09-03 the user explicitly directed that this iteration be backed up and its server-side automatic-update architecture removed from the main branch, then clarified that the Chrome plugin itself must remain at `0.5.167` at that rollback point. The exact full-stack state at commit `b2e33e2e5d29138891eabc93969cf24907492dfe` is preserved on remote branch `codex/backup-extension-update-20260903-b2e33e2`. Active `main` later advanced the manually distributed plugin to `0.5.169` and the control plane to migration 021 without restoring private-OSS/ECS update orchestration.
 
-This ADR is retained only as historical server-architecture context and no longer governs the active control plane. Plugin-side idle proof and guarded reload handlers remain as dormant `0.5.167` capabilities with no current server/platform trigger. The reverted server code was never deployed, migration 019 was not applied, no OSS extension release was published, and no Cloud Assistant or Chrome reload action was performed by these repository tasks.
+This ADR is retained only as historical server-architecture context and no longer governs the active control plane. Plugin-side idle proof and guarded reload handlers remain as dormant capabilities in `0.5.169` with no current server/platform trigger. The reverted server code was never deployed, migration 019 was not applied, no OSS extension release was published, and no Cloud Assistant or Chrome reload action was performed by these repository tasks.
 
 ## Context
 

.project-docs/10-decisions/decision-index.md

@@ -10,9 +10,10 @@
 | RELEASE-001 | Current artifacts, filenames, versions, and SHA-256 values are defined only by `dist/release-manifest.json`. | Active | 2026-08-28 | Release and delivery | [Release manifest](../../dist/release-manifest.json) |
 | SAFETY-001 | Real ERP access/write, task mutation, extension reload, service restart, deployment, and external delivery require explicit task-scoped authorization. | Active | 2026-08-28 | Operations and maintenance | [Governance](../../AGENTS.md) |
 | NETWORK-001 | In the trusted internal deployment, AgentBus roster attachment URLs may resolve to internal/private addresses; HTTPS, credential rejection, DNS pinning, redirect validation, bounds, and digest checks remain. | Active | 2026-08-31 | AgentBus attachment ingress | [Reply contract](../../agent设计规范/agentbus-reply-contract.md) |
-| AUTH-001 | The fixed deployment scope uses administrator-managed `admin`, `team_lead`, and `user` accounts, owner-isolated normal tasks, display-only leadership metrics with explicit filtering, explicit non-admin route grants, and assignee-bound AgentBus/browser/ERP execution. | Active except clauses superseded by AUTH-002 | 2026-09-01 | Authentication, authorization, audit, AgentBus workers, and operations oversight | [ADR](AUTH-001-fixed-scope-account-authorization.md) |
-| AUTH-002 | ERP execution is serialized per immutable assigned account, administrator visibility is never execution routing, and explicit force delete physically removes authorized tasks regardless of lifecycle state. | Active | 2026-09-03 | ERP claim queues, executable events/results, and task removal | [ADR](AUTH-002-account-scoped-execution-and-force-delete.md) |
+| AUTH-001 | The fixed deployment scope uses administrator-managed `admin`, `team_lead`, and `user` accounts, explicit employee route grants, and assignee-bound AgentBus/browser/ERP execution. | Active except clauses superseded by AUTH-002 and AUTH-004 | 2026-09-01 | Authentication, authorization, audit, AgentBus workers, and operations oversight | [ADR](AUTH-001-fixed-scope-account-authorization.md) |
+| AUTH-002 | ERP execution is serialized per immutable assigned account, and explicit owner force delete physically removes authorized tasks regardless of lifecycle state. | Active except administrator task-access clauses superseded by AUTH-004 | 2026-09-03 | ERP claim queues, executable events/results, and task removal | [ADR](AUTH-002-account-scoped-execution-and-force-delete.md) |
 | AUTH-003 | Active team-lead identities automatically receive an organization-wide read projection through their current-owner AgentBus route and a separate encrypted outbox; it never grants task or ERP authority. | Active | 2026-09-07 | Team-lead notifications, AgentBus outbound routing, and summary privacy | [ADR](AUTH-003-leader-task-summary-notifications.md) |
+| AUTH-004 | Administrators are management-plane-only identities; team leads alone receive an assignee-based, cross-source operations dashboard while employee task operations remain owner-only. | Active | 2026-09-07 | Administrator isolation, task APIs, database principals, and leadership oversight | [ADR](AUTH-004-admin-management-plane-and-leader-oversight.md) |
 
 ## Superseded And Reverted Decisions
 
@@ -20,7 +21,8 @@
 |---|---|---|---|
 | DOC-LEGACY-001 | Root `task_plan.md`, `findings.md`, and `progress.md` were the active project-memory system. | DOC-001 | 2026-08-28 |
 | AUTH-001 (partial) | Organization-wide ERP FIFO and archive-only operator removal. | AUTH-002 | 2026-09-03 |
-| EXT-001 | Central-service private-OSS and ECS Cloud Assistant orchestration for shared unpacked-extension updates. | Server architecture reverted by explicit user decision; exact full implementation is preserved on `codex/backup-extension-update-20260903-b2e33e2`, while plugin `0.5.167` remains current. | 2026-09-03 |
+| AUTH-001 / AUTH-002 (partial) | Administrator task creation, task-wide reads, dashboard access, task transitions, and force-delete authority; manual-only leadership dashboard scope. | AUTH-004 | 2026-09-07 |
+| EXT-001 | Central-service private-OSS and ECS Cloud Assistant orchestration for shared unpacked-extension updates. | Server architecture reverted by explicit user decision; exact full implementation remains on `codex/backup-extension-update-20260903-b2e33e2`, while the active manually distributed plugin has advanced to `0.5.169`. | 2026-09-03 |
 
 ## Decision Criteria