Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
19 changes: 11 additions & 8 deletions .agent-loop/LOOP_STATE.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,17 +2,20 @@

## Current State

- Active initiative: `WS-POL-002` - Post-Submit Checker Foundation
- Active planning chunk: none
- Active initiative: `WS-AUTH-001` - Workstream Authorization Service
- Active planning chunk: `WS-AUTH-001-PLAN`
- Active implementation chunk: none
- Branch: `main`
- Status: `WS-POL-002-02` merged through PR #88 as `32af6a7` on 2026-07-11
after internal review, current-head GitHub checks, CodeRabbit, and explicit
human merge approval.
- Branch: `authorization-service`
- Status: WS-AUTH-001 planning is internally reviewed and stopped at the L0
human checkpoint. D1-D3 are approved; D4-D10 require explicit approval.
- Last merged implementation SHA: `67fb3ca`
- Last merge commit: `32af6a7`
- Current gate: none; awaiting explicit user start for the next chunk.
- Next chunk: `WS-POL-002-03` is inactive until the user explicitly starts it.
- Current gate: explicit durable human approval of D4-D10. Planning evidence is
recorded at the WS-AUTH-001 internal review evidence path.
- Next chunk: `WS-AUTH-001-01` remains proposed until D4-D10 approval and a
separate implementation start signal.
- Paused initiative: `WS-POL-002`; chunk `WS-POL-002-03` must not start before
the relevant authorization foundation and an explicit resume signal.

## Operating Rule

Expand Down
29 changes: 29 additions & 0 deletions .agent-loop/REVIEW_LOG.md
Original file line number Diff line number Diff line change
Expand Up @@ -580,3 +580,32 @@ Trust bundle: `.agent-loop/initiatives/WS-POL-002-post-submit-checker-foundation

Next gate: `WS-POL-002-01` Post-Submit Provenance And Compiler Contract. No
implementation chunk is active until the user explicitly starts it.

## 2026-07-11 - WS-AUTH-001-PLAN Internal Review Passed

Required reviewer tracks:

- senior engineering
- QA/test
- security/auth
- product/ops
- architecture
- docs
- CI integrity
- reuse/dedup
- test delta

Result: PASS after plan repairs. The reviewed planning tree preserves the
external Flow authentication boundary, replaces token roles only through a
staged local-grant cutover, keeps `/api/v1`, protects intermediate-release
operability, and leaves all runtime implementation inactive.

Scope: imported and hash-bound eight Workstream reference files; added the
WS-AUTH-001 intent, discovery, decisions, risks, plan, source manifest, status,
16 implementation chunk contracts, and durable WS-POL-002 pause. D1-D3 are
human-approved. D4-D10 remain at the L0 human approval checkpoint.

Evidence: `.agent-loop/initiatives/WS-AUTH-001-workstream-authorization-service/reviews/WS-AUTH-001-PLAN-internal-review-evidence.md`

Next gate: stop. Do not activate `WS-AUTH-001-01` without explicit human
approval of D4-D10 and a separate implementation start signal.
13 changes: 11 additions & 2 deletions .agent-loop/WORK_QUEUE.md
Original file line number Diff line number Diff line change
@@ -1,10 +1,17 @@
# Work Queue

## In Progress

| Chunk | Title | Risk | Status |
|---|---|---:|---|
| `WS-AUTH-001-PLAN` | Authorization Service Planning | L0 | Internal review passed; explicit D4-D10 human approval pending |

## Planned Next

| Chunk | Title | Risk | Status |
|---|---|---:|---|
| `WS-POL-002-03` | Server-Owned Policy Approval And Visibility APIs | L1 | Inactive until explicit user start |
| `WS-AUTH-001-01` | Adopt Authorization Baseline And Repository Contracts | L1 | Proposed after D4-D10 approval and explicit start |
| `WS-POL-002-03` | Server-Owned Policy Approval And Visibility APIs | L1 | Paused behind WS-AUTH-001 and explicit resume |

## Completed

Expand Down Expand Up @@ -35,7 +42,9 @@

## Proposed Next

Do not start `WS-POL-002-03` until the user gives an explicit start signal.
Stop at the WS-AUTH-001 planning human checkpoint. Do not activate
`WS-AUTH-001-01` before explicit D4-D10 approval and a separate start signal;
do not resume `WS-POL-002-03` while auth has priority.

## Blocked

Expand Down
Original file line number Diff line number Diff line change
@@ -0,0 +1,75 @@
# Chunk Map: WS-AUTH-001 - Workstream Authorization Service

## Rule

Only one chunk may be active at a time. Do not start the next chunk until the
current chunk is implemented, verified, internally reviewed, externally
reviewed, merged by explicit human approval, followed by a memory update, and
stopped.

## Chunks

| Chunk | Title | Risk | Status |
|---|---|---:|---|
| `WS-AUTH-001-PLAN` | Authorization Service Planning | L0 | Internally reviewed; awaiting human approval |
| `WS-AUTH-001-01` | Adopt Authorization Baseline And Repository Contracts | L1 | Proposed |
| `WS-AUTH-001-02` | Verified Issuer Token And JWKS Boundary | L1 | Proposed |
| `WS-AUTH-001-03` | Legacy Actor Classification Preflight | L1 | Proposed |
| `WS-AUTH-001-04` | Request, Error, And API Control Foundation | L1 | Proposed |
| `WS-AUTH-001-05` | Authority Evidence And Idempotency Foundation | L1 | Proposed |
| `WS-AUTH-001-06` | Canonical Actor Profile And Identity Link | L1 | Proposed |
| `WS-AUTH-001-07` | Authorization Kernel And Permission Registry | L1 | Proposed |
| `WS-AUTH-001-08` | Bootstrap And Administrative Role Grants | L1 | Proposed |
| `WS-AUTH-001-09` | Actor State, Identity Revocation, And Service Actors | L1 | Proposed |
| `WS-AUTH-001-10` | Project Qualification And Contributor Role Grants | L1 | Proposed |
| `WS-AUTH-001-11` | Project Identity, Guide, Source, And Visibility Cutover | L1 | Proposed |
| `WS-AUTH-001-12` | Project Policy And Setup Mutation Cutover | L1 | Proposed |
| `WS-AUTH-001-13` | Task Management And Assignment Cutover | L1 | Proposed |
| `WS-AUTH-001-14` | Submission, Checker, And Audit Visibility Cutover | L1 | Proposed |
| `WS-AUTH-001-15` | Remaining System Worker Cutover And Obsolete Authority Removal | L1 | Proposed |
| `WS-AUTH-001-16` | Conformance, Observability, And Live API Proof | L1 | Proposed |

## Dependency order

```text
WS-AUTH-001-PLAN
-> WS-AUTH-001-01
-> WS-AUTH-001-02
-> WS-AUTH-001-03
-> WS-AUTH-001-04
-> WS-AUTH-001-05
-> WS-AUTH-001-06
-> WS-AUTH-001-07
-> WS-AUTH-001-08
-> WS-AUTH-001-09
-> WS-AUTH-001-10
-> WS-AUTH-001-11
-> WS-AUTH-001-12
-> WS-AUTH-001-13
-> WS-AUTH-001-14
-> WS-AUTH-001-15
-> WS-AUTH-001-16
```

## Boundary notes

- Chunk 02 authenticates tokens but grants no product authority.
- Chunk 03 provides a supported classification gate before schema migration.
- Chunk 04 establishes request/error/rate controls.
- Chunk 05 evolves the shared audit path and idempotency before mutations.
- Chunk 06 establishes canonical actor resolution while preserving only the
enumerated non-authoritative legacy workflow-eligibility consumers required
for intermediate-release operability.
- Chunk 07 provides the single authorization engine before grant APIs.
- Chunks 08-10 establish local grant truth before product cutover.
- Chunks 11-15 migrate bounded complete product/system surfaces.
- Chunk 16 proves the complete initiative; it does not backfill missing audit
or idempotency evidence.
- `WS-POL-002-03` remains paused until the relevant project authorization
cutover is complete and the user explicitly resumes it.

## Stop condition

After planning review, stop. `WS-AUTH-001-01` does not become active without
explicit human approval of D4-D10 plus an implementation start signal under the
repository engineering loop.
Original file line number Diff line number Diff line change
@@ -0,0 +1,106 @@
# Decisions: WS-AUTH-001 - Workstream Authorization Service

## D1: Adopt WS-AUTH-001 as the authorization authority source

Status: accepted by the user on 2026-07-11.

`WS-AUTH-001` supersedes the repository's token-role bootstrap and current
multi-profile authorization semantics. Existing code and docs remain evidence
of current behavior, not the target authority contract.

## D2: Preserve `/api/v1`

Status: accepted by the user on 2026-07-11.

The repository's existing `/api/v1` namespace remains canonical. The imported
specification's `/v1` examples will be reconciled during the baseline-adoption
chunk. Workstream will not expose two versioned route trees as permanent
aliases.

## D3: Prioritize auth before WS-POL-002-03

Status: accepted by the user on 2026-07-11.

`WS-POL-002` is paused after merged chunk 02. New post-submit approval APIs must
not be built on authority rules that have been declared obsolete.

## L0 human approval boundary

The user explicitly approved the authorization direction, source precedence,
API namespace, and priority recorded in D1-D3 on 2026-07-11. The remaining
architecture and data-model choices in D4-D10 are proposed planning decisions,
not autonomous implementation authority. Their explicit human approval must be
recorded durably before `WS-AUTH-001-01` becomes active. Every bounded
implementation chunk is then L1 and retains its own human PR/merge checkpoint.

## D4: No dual canonical authority

Status: planning decision derived from the adopted contract.

Token roles may be retained as non-authoritative diagnostic input during a
bounded migration only. A protected command must never accept either a token
role or a local permission as interchangeable proof. Cutover chunks replace
authorization for complete resource surfaces and remove the old check.

## D5: Preserve historical actor identifiers where classification is safe

Status: planning decision.

Existing `ActorIdentity.actor_id` values for externally verified callers are
UUID5 strings and are referenced throughout tasks, submissions, checker runs,
project provenance, and audit rows. For a classified legacy row, that UUID
becomes the canonical `ActorProfile.id`; the new `ActorIdentityLink` receives a
separate UUID. Migration must validate UUID shape and uniqueness before reuse.
Invalid or ambiguous rows fail preflight and are not silently rewritten.

The unrelated UUIDs on legacy typed `actor_profiles` rows are workflow-row IDs,
not actor IDs, and never become canonical profile IDs.

## D6: Existing typed profiles do not become grants

Status: planning decision.

Observed or active `worker`, `reviewer`, `admin`, or `project_manager` profile
rows do not create `AdminRoleGrant` or `ProjectRoleGrant` records. Skills and
non-authoritative workflow metadata may be preserved under a clearly named
metadata model only when required by an existing workflow.

## D7: Internal workers use explicit system authority

Status: planning decision.

Project setup, pre-review gating, reconciliation, and repair work use fixed
Workstream system principals and registered system permissions. They do not
receive fabricated human admin roles and do not become normal ActorProfiles.

## D8: Production issuer details remain configuration

Status: planning decision.

The token adapter will require explicit issuer, audience, JWKS URL, algorithm,
scope, clock-skew, and cache configuration and will fail closed when incomplete.
The real issuer values are required for live production-token proof, not for
deterministic adapter implementation with local JWKS fixtures.

## D9: Authority evidence is foundational

Status: planning repair after internal review.

Request/correlation context, canonical idempotency records, and the shared
append-only authority-event writer are introduced before canonical actor
persistence and before any authority-changing public API. Every later authority
mutation commits state, idempotency result, audit event, and invalidation event
atomically. The final evidence chunk verifies completeness; it does not invent
or backfill the evidence model.

## D10: Legacy classification uses a versioned supported manifest

Status: planning repair after internal review.

Non-empty legacy registries require a versioned JSON classification manifest
processed by a supported management/preflight tool. Entries bind exact legacy
actor ID, canonical issuer, opaque subject, and `subject_kind`. The tool rejects
duplicates, stale/missing rows, mismatches, unknown fields, and unsupported
kinds; supports dry-run; emits a checksum-bound report; and never writes grants.
The schema migration consumes only validated staged classification evidence or
fails closed. Manual SQL is not a supported path.
Loading
Loading