Make sandbox the only active DataOps deployment and rollout target

[alexeygrigorev]

Make sandbox the only active DataOps deployment and rollout target

Status: source accepted by Architecture, Security, Tester, and PM; source commits and protected-boundary activation remain incomplete
Tags: bug, infra, testing, migration, P0
Depends on: None — this pre-#136 boundary repair can proceed while #143 independently owns Sponsor table ownership reconciliation
Blocks: #136 directly; #30, #41, #71, #108, #113–#115, #120–#129, #131, #134, and #137 at their current deployment, migration, provider-smoke, or rollout gates
Next owner: Software Engineer to commit both accepted source candidates on their review branches without activation; then the authorized GitHub environment administrator, sandbox AWS operator, and orchestrator follow the documented environment → trust → workflow order
Resume condition: commit accepted source without activation; configure/read back exact dataops-v1-sandbox; then integrate/apply/read back exact trust; only then activate the accepted DataOps workflow and verify source CI. #136 still resumes only after its independent #143 ownership prerequisite and fresh gates also pass

Authoritative product decision

DataOps runs only in the shared AWS sandbox for now. Current work must not require, create, select, deploy, mutate, smoke-test, or roll out a production target. Any future production work requires new user authorization and a separately groomed issue.

The current stack, role, table, bucket, and domain names are legacy neutral identities. Do not rename or replace them under this correction. Sandbox also does not declassify Sponsor, finance, contact, Telegram, Mailchimp, Trello, or other operational data; existing privacy, integrity, backup, retention, rollback, and explicit HUMAN controls remain.

Current state and issue graph

• Shared sandbox infrastructure is sourced from ../aws-infra/sandbox/dataops/.
• Ordinary application deployment uses .github/workflows/deploy-dataops-v1.yml, the exact main branch OIDC subject, samconfig.toml environment full-sandbox, and stack dataops-v1.
• The protected Sponsor migration incorrectly references nonexistent GitHub environment dataops-v1-production.
• The effective sandbox deploy-role trust currently admits only the exact main branch subject. An environment-protected job receives an environment subject, so the exact sandbox-environment subject must be added without removing or broadening the branch subject.
• Reconcile Sponsor CRM table ownership with CloudFormation #143 independently blocks Migrate Sponsor CRM GSIs in a protected stage-only workflow #136 on Sponsor table ownership. Provide one short-lived CloudTrail Event History audit session #141 is not a blocker. Completing Make sandbox the only active DataOps deployment and rollout target #145 does not satisfy Reconcile Sponsor CRM table ownership with CloudFormation #143, authorize Migrate Sponsor CRM GSIs in a protected stage-only workflow #136 dispatch, or prove table ownership.
• Through Migrate Sponsor CRM GSIs in a protected stage-only workflow #136, the current application/Sponsor/Telegram closure chain remains blocked. Real provider or operational-data gates outside that chain must also identify sandbox before they run.

Scope A — exact DataOps workflow correction

Change only the protected migration boundary and its direct public-safe documentation/tests:

• .github/workflows/migrate-sponsor-crm-gsis.yml
• scripts/deploy/README.md
• scripts/deploy/sponsor-crm-gsi-core.test.mjs

Required behavior:

1. Replace the migration job environment with exact dataops-v1-sandbox.
2. Preserve workflow_dispatch as the only trigger, actor/repository/main-ref validation, shared non-cancelling deployment concurrency, existing OIDC role, migration command, and every Migrate Sponsor CRM GSIs in a protected stage-only workflow #136 fail-closed ownership/state check.
3. Preserve the ordinary deploy workflow and its exact accepted SAM command byte-for-byte. Do not add migration behavior to it or application deployment to the migration workflow.
4. Prove no active workflow in this repository names or selects a production environment/target.
5. Do not change infra/template.full.yaml, samconfig.toml, application resources, migrator/guard runtime logic, stack/resource names, flags, or provider configuration in this issue.

Because this changes one path in #136's accepted workflow fingerprint, freeze a new exact base/path/tree/diff fingerprint and require fresh Architecture/Security consideration before any later #136 dispatch. Preserve the accepted #136 implementation and test evidence; do not represent the old fingerprint as the new candidate.

Scope B — exact additive sandbox OIDC trust

Use a clean isolated ../aws-infra worktree created from current origin/main. The existing ../aws-infra checkout is dirty and contains user-owned changes and missing worktree files; do not modify, restore, stage, stash, reset, or commit anything in that checkout.

Change only:

• ../aws-infra/sandbox/dataops/template.github-actions.yaml
• ../aws-infra/sandbox/dataops/tests/test_template_github_actions.py
• ../aws-infra/sandbox/dataops/README.md only for the exact public-safe trust explanation

The deploy-role trust must accept exactly two sub values for DataTalksClub/dataops:

1. the existing exact main branch subject used by ordinary sandbox deployment; and
2. the exact dataops-v1-sandbox environment subject used by the protected migration.

Keep exact aud=sts.amazonaws.com. The environment name may be a CloudFormation parameter only if its allowed values are restricted to exactly dataops-v1-sandbox; no caller-selected alternate environment is allowed.

Reject every wildcard, pull-request, tag, other branch, other environment including dataops-v1-production, other repository/owner, alternate audience, StringLike, or missing condition. Do not alter any permission-policy action/resource, managed-policy attachment, session duration, role name, stack name, account/region boundary, retention policy, or unrelated resource. Tests must recompute the expected trust/source fingerprints and prove all prior #129/#130/#131/#135/#138/#139 permission and negative cases remain exact.

A source commit or push does not make this trust effective. aws-infra has no self-deploying CI/CD path for this stack.

Scope C — protected sandbox environment HUMAN gate

After accepted source is integrated, an authorized GitHub environment administrator must configure exact dataops-v1-sandbox with:

• deployment branch policy permitting only main;
• at least one required reviewer independent from the dispatching actor;
• self-review prevented;
• administrator bypass disabled; and
• no production environment, secret, variable, or deployment target created by this issue.

Public evidence contains only environment name, sanitized rule counts/results, UTC verification time, verifier role, and PASS/FAIL. Do not publish reviewer identity/contact details, screenshots, private links, secrets, or provider/resource identifiers. Environment configuration does not authorize workflow dispatch.

Scope D — effective trust HUMAN gate

After the reviewed aws-infra source is integrated, an authorized sandbox AWS operator must:

1. create and review a change set for the existing deploy-role stack;
2. require exactly one non-replacing deploy-role trust-policy modification and no permission, attachment, role-name, session, tag, or unrelated-resource change;
3. apply only that accepted change set;
4. wait for a terminal successful stack state; and
5. record a sanitized read-only comparison proving the two exact allowed subject classes and all permission policies unchanged.

No agent or grooming action authorizes this AWS mutation. Do not dispatch the Sponsor migration to test the trust. The first migration dispatch remains owned by #136 after #143 and every #136 gate pass.

Bounded tracker reconciliation

After the source target and protected-boundary design are accepted, Product Manager updates only current status/dependency/resume text and unchecked environment-specific HUMAN criteria that incorrectly require production in:

• Implement assistant job model and lifecycle #30, Migrate active Trello cards into integrated operations-manager work #41, and Coordinate V1 production cutover and human-gate closeout #71;
• Automate private Mailchimp account exports and attach them to recurring work #108, Connect sponsor bookings to invoice and payment follow-through #113–Migrate and reconcile historical sponsor CRM data #115, Integrate DataOps with the shared Cognito browser login #119–Epic: Deliver a Telegram-first conversational agent MVP #122, Add transactional approval and durable execution recovery #124–Repair DataOps OIDC SES configuration-set tag-on-create permission #129, Allow OIDC deployment of Telegram rollout alarms and notifications #131, and Use one Berlin business date in #106 scheduling and default-SPA E2E #134;
• Migrate Sponsor CRM GSIs in a protected stage-only workflow #136, Reconcile four retained failure queues after a successful replacement deploy #137, Reconcile missing CloudFormation ownership provenance for Sponsor CRM table #140, and Reconcile Sponsor CRM table ownership with CloudFormation #143.

Use sandbox deployment, sandbox migration, sandbox provider smoke, or sandbox operational-data wording as applicable. Do not mechanically rewrite generic deployed-code terms such as production transaction/client/runtime paths, checked implementation criteria, historical comments, review verdicts, workflow runs, fingerprints, or evidence links. #140's route-A rejection and #141's evidence boundary remain unchanged. #143 still requires an independently accepted ownership path unless fresh Architecture/Security review explicitly changes it.

Acceptance criteria

• The migration workflow uses exact protected environment dataops-v1-sandbox; no active workflow names or selects a production target.
• Migration remains manual-only, main-only, actor/repository-bound, non-cancelling, migration-only, and fail-closed under the complete accepted Migrate Sponsor CRM GSIs in a protected stage-only workflow #136 contract.
• The ordinary deploy workflow, exact SAM command, application template, full-sandbox config, runtime resources, stack/resource names, flags, and provider configuration are unchanged.
• The sandbox deploy-role trust accepts exactly the existing main-branch subject and the new dataops-v1-sandbox environment subject with exact audience; every broader or alternate subject/audience is rejected.
• No deploy-role permission, resource scope, attachment, role/session property, retention control, or unrelated aws-infra resource changes.
• Work occurs in clean isolated worktrees; both dirty main checkouts and all unrelated user-owned changes remain untouched.
• DataOps and aws-infra candidates record exact bases, NUL-safe path inventories, tree/diff/file hashes, and clean focused diffs for independent review.
• DataOps Sponsor migration tests and infrastructure tests cover the sandbox environment, workflow split, unchanged application deploy command, and rejection of production/alternate targets.
• aws-infra parsed and adversarial tests cover exact two-subject trust, exact audience, production/other subject rejection, unchanged permission-policy fingerprints, quotas/counts, and no replacement/broadening.
• Architecture accepts the workflow/trust shape and confirms Migrate Sponsor CRM GSIs in a protected stage-only workflow #136 assumptions requiring fresh review are explicitly carried forward.
• Security accepts exact OIDC subjects, independent-review protection, no bypass/wildcard, unchanged least privilege, and sanitized evidence boundaries.
• Tester runs the full commands below, verifies every criterion, and records exact exit codes/test counts; no UI changed, so browser screenshots are not required.
• PM accepts the sandbox-only operator flow and performs the bounded current-tracker reconciliation without rewriting historical evidence.
• Software Engineer commits accepted DataOps changes with Refs #145; accepted aws-infra changes use Refs DataTalksClub/dataops#145 through that repository's approved integration path. Neither commit closes Make sandbox the only active DataOps deployment and rollout target #145 before HUMAN gates.
• On-Call verifies post-push source CI. A known Migrate Sponsor CRM GSIs in a protected stage-only workflow #136/Reconcile Sponsor CRM table ownership with CloudFormation #143 guard failure is recorded as fail-closed and never bypassed or reclassified as deployment success.
• [HUMAN] An authorized operator applies and verifies the exact sandbox OIDC trust change from the accepted source revision.
• [HUMAN] An authorized administrator configures and verifies dataops-v1-sandbox with main-only deployment, an independent required reviewer, no self-review, and no administrator bypass.
• No migration dispatch, application deploy, provider call, Telegram action, feature enablement, queue action, private-evidence inspection, or data mutation occurs under Make sandbox the only active DataOps deployment and rollout target #145.

Required verification

From the DataOps repository:

npm run test:sponsor-gsi-migrator
uv run --with pytest python -m pytest -q tests/infra
git diff --check <accepted-dataops-base>...HEAD

Also parse all active .github/workflows/*.yml and assert that the migration uses only dataops-v1-sandbox, no active workflow contains dataops-v1-production, and the ordinary deploy workflow/SAM command digest equals the accepted pre-#145 value.

From the clean isolated aws-infra worktree:

uv run --with pytest python -m pytest sandbox/dataops/tests -q
sam validate --lint --template-file sandbox/dataops/template.github-actions.yaml
git diff --check <accepted-aws-infra-base>...HEAD

Tester must inspect the parsed CloudFormation trust object and mutation cases, not rely only on substring checks. No AWS-backed validation, workflow dispatch, browser test, or screenshot is required for the agent-verifiable stage.

Test scenarios

Ordinary sandbox deployment retains its identity

Given the exact existing main branch OIDC subject
When the trust policy is rendered and parsed
Then it remains accepted with exact audience and every permission policy remains byte-equivalent.

Protected sandbox migration receives an environment subject

Given a manually dispatched migration from main after environment approval
When GitHub issues the dataops-v1-sandbox environment subject
Then the exact subject is admitted and no other environment subject is admitted.

Production or alternate target is attempted

Given a production, pull-request, tag, other-branch, other-environment, other-owner/repository, wildcard, or alternate-audience subject
When trust and workflow tests evaluate it
Then it fails closed before credentials or migration work.

Environment is absent or under-protected

Given dataops-v1-sandbox is missing, permits a non-main branch, lacks an independent reviewer, permits self-review, or permits administrator bypass
When the HUMAN gate is reviewed
Then #145 and #136 remain blocked and no dispatch occurs.

Existing ownership blocker remains

Given #145 source and HUMAN boundary gates pass while #143 remains incomplete
When #136 readiness is assessed
Then migration/deployment remain blocked; sandbox naming does not establish Sponsor table ownership.

Tracker text is reconciled

Given current issue bodies still describe active production gates
When PM performs bounded reconciliation
Then current routing says sandbox-only, future production requires new authority, and historical evidence remains unchanged.

Deferred child boundary

Runtime/export labeling is deliberately excluded before #136. Do not change DataOpsEnvironment, DATAOPS_ENV, the application template, or the ordinary deploy parameter list under #145: those bytes participate in #136's accepted template/deploy contract.

After #136 reaches accepted sandbox migration completion and the ordinary sandbox deploy succeeds, a separate child may change runtime/export labeling from prod to sandbox with a no-replacement change-set proof. #145 must not create or implement that child.

Out of scope

• Any production environment, deployment, data action, smoke, rollout, or future-production design.
• Dispatching/rerunning migration or application workflows.
• Changing Sponsor ownership logic, GSI state-machine behavior, Reconcile Sponsor CRM table ownership with CloudFormation #143 evidence requirements, or table/resource identity.
• Changing infra/template.full.yaml, samconfig.toml, .github/workflows/deploy-dataops-v1.yml, application runtime, export schemas, DataOpsEnvironment, or DATAOPS_ENV.
• Renaming stacks, roles, tables, buckets, queues, functions, domains, or retained resources.
• Provider/Telegram calls, feature enablement, operational-data writes, queue reconciliation, Support contact, private-evidence inspection, or cleanup.
• Modifying source repositories other than the exact ../aws-infra paths explicitly authorized above.

[alexeygrigorev]

PM GROOMED — sandbox-only pre-#136 boundary is agent-ready

The authoritative correction is now expressed as the smallest safe pre-#136 change:

• DataOps changes only the protected Sponsor migration environment plus its direct documentation/test.
• aws-infra adds exactly the sandbox-environment OIDC subject while retaining the exact ordinary main branch subject and every permission boundary.
• HUMAN gates separately apply/read back the trust and configure dataops-v1-sandbox with main-only deployment, an independent reviewer, no self-review, and no administrator bypass.
• No workflow dispatch, application deploy, provider call, feature enablement, private-evidence access, or data mutation is authorized.
• Reconcile Sponsor CRM table ownership with CloudFormation #143 remains the independent Sponsor ownership blocker for Migrate Sponsor CRM GSIs in a protected stage-only workflow #136; Make sandbox the only active DataOps deployment and rollout target #145 cannot satisfy or bypass it.

The current dirty aws-infra checkout is explicitly excluded. SWE must use a clean isolated worktree from current origin/main and preserve all user-owned changes.

Runtime/export DataOpsEnvironment labeling is excluded because changing the application template or ordinary deploy parameters before #136 would invalidate its accepted template/deploy contract. A concise post-#136 raw child intake is returned separately to the orchestrator; no child was created.

needs grooming is removed and the issue now has bug, infra, testing, migration, and P0. Exact next role: Software Engineer, producing the frozen two-repository candidate without AWS/GitHub-environment mutation and without committing before Architecture, Security, Tester, and PM review.

[alexeygrigorev]

ARCHITECTURE BLOCK — candidate bytes are sound; cross-repository activation order is not closed

I independently reviewed only the two frozen uncommitted candidates and made no edit, commit, AWS call, workflow dispatch, GitHub-environment change, or private-evidence inspection.

Fingerprint binding

DataOps:

• worktree: /home/alexey/git/dataops/.tmp/worktrees/issue-145
• base/HEAD: b9470340c2837931a7c1c0cb0cb2148b82216cc7
• exact three-path candidate tree: 7df62fa5eab070f551b30e4e89c4c2e15e3ead6c
• full-index binary diff SHA-256: 76ce90f72c181e2735705f47959ce7ed6608e5b2b2036c5ba1b7c8d70b4c0366

aws-infra:

• worktree: /home/alexey/git/aws-infra-worktrees/issue-145-sandbox-oidc
• base/HEAD: d370385556344bb6841f88473c12397c326a6b5a
• exact three-path candidate tree: 79ad598d96f69097ded0aa780d83b9c6dc5558ca
• full-index binary diff SHA-256: 6700afbab784b0c94cc25e1b4428cd137e5e8610202ef394948b2124a1dd0472

Both path inventories are exact and git diff --check is clean.

Static architecture findings

PASS — exact trust shape. The sandbox deploy-role trust retains exact audience sts.amazonaws.com and the exact ordinary DataTalksClub/dataops main-branch subject, then adds only the exact dataops-v1-sandbox environment subject. Owner/repository/branch parameters are additionally closed to their one accepted value. There is no StringLike, wildcard subject, production subject, alternate branch/tag/PR/environment/repository, or alternate audience in the accepted trust object. Parsed mutation tests cover these rejections.

PASS — unchanged least privilege and identities. The aws-infra template diff changes only parameter constraints and AssumeRolePolicyDocument; it changes no permission action/resource, managed-policy attachment, role/session property, retention property, stack/resource identity, or unrelated resource. Existing permission fingerprints remain frozen in tests. The DataOps diff changes only the migration workflow, direct public documentation, and focused test; application template, samconfig.toml, migrator/guard runtime, package files, stack/resource names, flags, and provider configuration are unchanged.

PASS — ordinary deploy/SAM bytes. .github/workflows/deploy-dataops-v1.yml remains byte-identical with SHA-256 4611d88891fcb3031a94b0140b7238686e6e68feb68824ac7332d1a71180b14c; infra/template.full.yaml and samconfig.toml are also byte-identical to the supplied DataOps base. The focused test pins the ordinary deploy workflow digest.

PASS — sandbox-only active workflow target. The migration now names only dataops-v1-sandbox; the active workflow inventory contains no production environment/target. Manual-only trigger, actor gate, shared non-cancelling concurrency, OIDC role, and migration-only command remain unchanged.

PASS with required carry-forward — #136 fingerprint. This deliberately changes #136’s migration-workflow bytes, so its earlier accepted full candidate fingerprint cannot authorize dispatch. The new #145 fingerprint and later effective environment/trust evidence must be inputs to fresh #136 Architecture/Security review after #143; historical #136 evidence remains historical.

Blocking finding — unsafe activation-order window

The code and trust are individually correct, but neither candidate nor the current #145 sequencing defines one mandatory cross-repository activation order.

An environment-bound GitHub OIDC token uses the environment subject and no longer carries the branch subject. If the new sandbox environment subject is applied to AWS trust before dataops-v1-sandbox exists with main-only deployment, an independent required reviewer, self-review prevention, and administrator-bypass prevention, a workflow job referencing that name can receive the now-admitted subject without the intended GitHub protection boundary. The workflow runtime checks do not replace the missing pre-credential environment approval.

The current issue says both HUMAN actions happen after source integration but does not order environment configuration versus effective trust versus DataOps workflow activation. The READMEs describe the subjects but not a monotonic activation sequence. “No dispatch is authorized” is necessary but is not a technical prevention against accidental or premature dispatch.

Required repair

Freeze a replacement candidate and update the public-safe source/handoff contract to require this exact order:

1. Review and commit source only; do not dispatch, apply trust, or merge/push the DataOps workflow yet.
2. Create/configure/read back exact dataops-v1-sandbox first and prove main-only deployment, at least one independent required reviewer, self-review prevented, and administrator bypass disabled.
3. Integrate the accepted aws-infra source and apply/read back the exact two-subject trust only after step 2 passes. Source integration alone remains non-effective.
4. Merge/push the accepted DataOps workflow only after steps 2–3 pass.
5. Do not dispatch. Migrate Sponsor CRM GSIs in a protected stage-only workflow #136 remains blocked on Reconcile Sponsor CRM table ownership with CloudFormation #143 and its fresh Architecture/Security/HUMAN gates.

Alternatively, another sequence may pass only if it proves there is never an interval in which an active workflow can obtain the environment subject before all GitHub protections are effective. State the proof explicitly; inference from actor intent is insufficient.

At minimum, place the order in the durable public-safe deployment documentation already touched by this candidate and reconcile the #145 role/release sequence. Add a focused assertion if the order is represented in machine-readable workflow/configuration state. Preserve all passing trust, permission, workflow, identity, and ordinary-deploy properties above.

Verdict: ARCHITECTURE BLOCK. Re-review only a newly frozen two-repository fingerprint after the activation order is explicit. Tester commands remain for the Tester role; this architecture review did not substitute for them.

[alexeygrigorev]

SECURITY PASS — exact frozen source candidates only

I independently reviewed the two uncommitted candidates against the complete #145 sandbox-only contract. I made no source edit, commit, AWS call, GitHub environment/configuration change, workflow dispatch, Support contact, or private-evidence inspection.

Frozen fingerprints

DataOps:

• base: b9470340c2837931a7c1c0cb0cb2148b82216cc7
• reconstructed candidate tree: 7df62fa5eab070f551b30e4e89c4c2e15e3ead6c
• full binary diff SHA-256: 76ce90f72c181e2735705f47959ce7ed6608e5b2b2036c5ba1b7c8d70b4c0366
• exact paths: migration workflow, direct deployment-gate README, Sponsor migrator test

aws-infra:

• base: d370385556344bb6841f88473c12397c326a6b5a
• candidate tree: 79ad598d96f69097ded0aa780d83b9c6dc5558ca
• full binary diff SHA-256: 6700afbab784b0c94cc25e1b4428cd137e5e8610202ef394948b2124a1dd0472
• exact paths: sandbox DataOps trust template, its direct README, its tests

Both diffs pass git diff --check; both worktrees contain only the three declared modified paths.

Trust and least-privilege decision

The deploy-role trust remains one exact Allow statement for the existing GitHub OIDC provider and sts:AssumeRoleWithWebIdentity. Its Condition contains only StringEquals with:

• exact aud=sts.amazonaws.com;
• exact existing repo:DataTalksClub/dataops:ref:refs/heads/main subject; and
• exact new repo:DataTalksClub/dataops:environment:dataops-v1-sandbox subject.

Owner, repository, and branch parameters are additionally restricted to their one exact allowed value, so the substitutions cannot be caller-selected. Parsed/adversarial tests reject production or other environments, other branch/tag/pull-request subjects, other repository/owner, wildcard subjects, alternate audiences, StringLike, missing conditions, and parameter broadening.

The exact three-path diff changes no deploy permission action/resource, inline or managed-policy attachment, role name, maximum session duration, retention policy, stack/account/region/resource boundary, or unrelated resource. Existing exact permission-policy fingerprints, inventory, attachment counts, and quota checks remain green. The README correctly describes this as an additive trust change with permissions unchanged.

DataOps sandbox boundary

The migration changes only dataops-v1-production to exact dataops-v1-sandbox. It remains workflow_dispatch-only, exact-actor constrained, main/repository/runtime checked, under shared non-cancelling deployment concurrency, OIDC-based, and migration-only. The accepted #136 guard/migrator runtime and ownership state machine are untouched.

The ordinary deploy workflow is untouched and its complete source digest is pinned by the passing test. Parsed active-workflow coverage finds no production environment/target name. The candidate does not create or select a production resource, change legacy stack/resource identities, alter flags/providers/runtime labeling, or authorize use of production credentials/data. Sandbox continues not to declassify operational or Sponsor data.

Protected environment and evidence boundary

This PASS is source-only. The environment OIDC subject does not encode its branch/reviewer rules; therefore exact dataops-v1-sandbox remains blocked until an authorized administrator separately proves:

• only main may deploy;
• at least one required reviewer is independent from the dispatching actor;
• self-review is prevented; and
• administrator bypass is disabled.

Only the sanitized environment name, rule counts/results, UTC time, verifier role, and PASS/FAIL may be public. Reviewer identity/contact details, screenshots, private links, secrets, and provider/resource identifiers remain prohibited.

Likewise, source integration does not make the AWS trust effective. The later HUMAN change set must prove exactly one non-replacing trust-policy change and no permission, attachment, role/session, tag, or unrelated-resource change before an authorized sandbox operator applies it and records sanitized read-back evidence.

Neither HUMAN setup action authorizes dispatch. #143 remains the independent Sponsor ownership blocker, and #136 still requires its fresh gates. This review authorizes no environment mutation, AWS mutation, workflow run, deployment, provider call, feature enablement, queue/data action, or private evidence access.

Verification

• npm run test:sponsor-gsi-migrator — PASS, 64/64
• uv run --with pytest python -m pytest sandbox/dataops/tests -q — PASS, 72 tests / 181 subtests
• exact diff fingerprints and path inventories — PASS
• git diff --check in both worktrees — PASS

Verdict: SECURITY PASS for the two exact frozen source candidates. Advance to Tester and PM; preserve both separate HUMAN gates and every #136/#143 blocker.

[alexeygrigorev]

REPLACEMENT SECURITY PASS — README-only activation-order repair

I independently delta-reviewed the replacement candidates against the prior Security PASS and the Architecture activation-order block. I made no source edit, commit, AWS call, GitHub environment/configuration change, workflow dispatch, Support contact, or private-evidence inspection.

Replacement fingerprints

DataOps:

• base: b9470340c2837931a7c1c0cb0cb2148b82216cc7
• replacement candidate tree: 38687cbdf297530c5d37fd6509c871dec8a4f7dc
• full binary diff SHA-256: f9e7c7df7f416a580c7a6c938dedb27c7e6d222a2980852fdf648afa03aeae2c

aws-infra:

• base: d370385556344bb6841f88473c12397c326a6b5a
• replacement candidate tree: 081a96837d6d3d998a802e0b4762c629bdd1a733
• full binary diff SHA-256: 86553f62fa929b4ff222fc51df237802005fe996cb83150adc2f64faddf04d0c

Both worktrees still contain only the three owned paths and pass git diff --check. Relative to the previously passed trees, the exact delta is one file in each repository:

• DataOps: scripts/deploy/README.md only;
• aws-infra: sandbox/dataops/README.md only.

The migration workflow, Sponsor tests, OIDC trust template, and infrastructure tests are byte-identical to the prior Security-passed candidates. Therefore the prior exact two-subject StringEquals trust, exact audience, adversarial denials, unchanged permissions/attachments/role/session/resources, ordinary-deploy digest, and sandbox-only workflow findings remain valid for these replacement trees. Tester must still run the issue's required commands; this delta review does not replace Tester.

Security assessment of the partial order

The new durable documentation closes the unsafe interval with one mandatory monotonic order:

1. An authorized administrator creates/configures and reads back exact dataops-v1-sandbox, proving main-only deployment, an independent required reviewer, self-review prevention, and disabled administrator bypass.
2. Only after that proof passes may accepted aws-infra source be integrated and an authorized sandbox AWS operator apply/read back the exact additive two-subject trust with permissions unchanged.
3. Only after both proofs pass may the accepted DataOps workflow be merged to an active branch.
4. The workflow remains undispatched; Migrate Sponsor CRM GSIs in a protected stage-only workflow #136 stays blocked on Reconcile Sponsor CRM table ownership with CloudFormation #143 and fresh later gates.

This order is security-sound. Before step 2, AWS does not admit the environment subject. Between steps 2 and 3, the admitted subject is dormant because no active workflow names it, while the already-proven environment protection exists. After step 3, credential issuance remains behind the effective protected environment. Missing either proof blocks activation.

The recovery wording also remains fail-closed. If workflow source appears active prematurely, it keeps #145 blocked, forbids dispatch, and requires correction only through the normal reviewed source lifecycle. It explicitly forbids deleting or broadening either protection ad hoc. It does not authorize an agent or operator to mutate GitHub, AWS, trust, workflow state, or source outside the separately approved owner/gate and normal lifecycle.

Evidence and authorization boundary

The README additions contain only public-safe environment/issue names and control results. They add no reviewer identity, private link, screenshot, secret, raw provider/resource identifier, or operational evidence. #145's sanitized evidence contract remains unchanged.

These documents specify ordering; they grant no authority. Security PASS does not authorize environment creation/configuration, trust application, source integration, workflow dispatch, deployment, provider/data action, or private-evidence access. Each HUMAN operation still needs its exact owner and accepted gate. Trust source remains ineffective until separately applied and verified. Environment setup never authorizes dispatch. #143 remains independent and #136 remains blocked.

Verdict: REPLACEMENT SECURITY PASS for the two exact fingerprints above. The prior Security PASS is superseded only as a fingerprint binding; all of its substantive controls carry forward, now with the Architecture-required activation order closed.

[alexeygrigorev]

ARCHITECTURE PASS — monotonic activation and partial-state rollback are closed

I independently re-reviewed the replacement uncommitted candidates. I made no source edit, commit, AWS call, workflow dispatch, GitHub-environment change, or private-evidence inspection.

Replacement fingerprint binding

DataOps:

• base/HEAD: b9470340c2837931a7c1c0cb0cb2148b82216cc7
• independently reconstructed exact three-path candidate tree: 38687cbdf297530c5d37fd6509c871dec8a4f7dc
• full-index binary diff SHA-256: f9e7c7df7f416a580c7a6c938dedb27c7e6d222a2980852fdf648afa03aeae2c

aws-infra:

• base/HEAD: d370385556344bb6841f88473c12397c326a6b5a
• independently reconstructed exact three-path candidate tree: 081a96837d6d3d998a802e0b4762c629bdd1a733
• full-index binary diff SHA-256: 86553f62fa929b4ff222fc51df237802005fe996cb83150adc2f64faddf04d0c

Both worktrees contain only their three declared paths and both diffs pass git diff --check.

Original block repair

Both owned READMEs now impose the same exact monotonic activation order:

1. Source may be reviewed and committed on review branches, but the DataOps migration workflow reference must remain off every active branch.
2. An authorized GitHub environment administrator must first create, configure, and read back exact dataops-v1-sandbox, proving main-only deployment, at least one required reviewer independent from the dispatcher, self-review disabled, and administrator bypass disabled.
3. Only after that proof may accepted aws-infra source be integrated and an authorized sandbox AWS operator apply/read back the exact additive two-subject trust with unchanged permissions.
4. Only after both proofs pass may the accepted DataOps workflow reference be merged and activated.
5. Activation still does not authorize dispatch. Migrate Sponsor CRM GSIs in a protected stage-only workflow #136 remains blocked on Reconcile Sponsor CRM table ownership with CloudFormation #143 and its later fresh Architecture, Security, and HUMAN gates.

This removes the previously identified interval in which AWS could admit an environment subject before the GitHub protection boundary existed.

Partial-state and rollback review

The documented sequence fails closed in every rollout partial state:

• source only on review branches: no active workflow or effective credential path;
• protected environment only: no new AWS subject admission;
• protected environment plus exact trust, but no active workflow: the added trust remains dormant;
• active workflow: permitted only after both read-back proofs;
• workflow unexpectedly active without both valid proofs: Make sandbox the only active DataOps deployment and rollout target #145 remains blocked, dispatch is prohibited, and the workflow change is reverted through the normal reviewed source flow.

The proof chain must remain valid through activation; invalidation returns the rollout to the blocked/no-dispatch path. Rollback does not delete or broaden either protection ad hoc.

Carried-forward architecture findings

The workflow, trust template, and tests are unchanged from the previously inspected source candidate; the replacement changes only the two owned README contracts. Reinspection of the complete current diffs confirms:

• exact aud=sts.amazonaws.com and exactly the existing main-branch subject plus dataops-v1-sandbox environment subject;
• no wildcard, StringLike, production, alternate environment/branch/tag/PR/repository/owner/audience path;
• unchanged deploy-role permission actions/resources, attachments, role/session properties, retention controls, and legacy identities;
• migration remains manual-only, actor-bound, shared non-cancelling, OIDC-based, and migration-only;
• ordinary deploy/SAM bytes and application infrastructure remain outside this change.

The #136 migration-workflow fingerprint remains invalidated by #145. Historical #136 acceptance cannot authorize dispatch; fresh reviews and effective-boundary evidence are still required after #143.

Verdict: ARCHITECTURE PASS for only the two replacement fingerprints above. The earlier Security verdict is bound to the superseded trees, so the next specialist gate is Security re-review of these exact bytes, followed by Tester and PM. This pass authorizes no environment/AWS mutation, merge, push, deployment, or dispatch.

[alexeygrigorev]

TEST PASS — exact replacement two-repository source candidates

I independently tested the two frozen uncommitted replacement candidates supplied by the orchestrator and bound by the replacement Security and Architecture PASS comments. I did not edit source, commit, push, call AWS, configure a GitHub environment, dispatch a workflow, deploy, inspect private evidence, or mutate application/data state.

Frozen fingerprint binding

DataOps worktree /home/alexey/git/dataops/.tmp/worktrees/issue-145:

• base/HEAD: b9470340c2837931a7c1c0cb0cb2148b82216cc7
• independently reconstructed candidate tree: 38687cbdf297530c5d37fd6509c871dec8a4f7dc
• full-index binary diff SHA-256: f9e7c7df7f416a580c7a6c938dedb27c7e6d222a2980852fdf648afa03aeae2c
• exact NUL-safe inventory: .github/workflows/migrate-sponsor-crm-gsis.yml, scripts/deploy/README.md, scripts/deploy/sponsor-crm-gsi-core.test.mjs

aws-infra worktree /home/alexey/git/aws-infra-worktrees/issue-145-sandbox-oidc:

• base/HEAD: d370385556344bb6841f88473c12397c326a6b5a
• independently reconstructed candidate tree: 081a96837d6d3d998a802e0b4762c629bdd1a733
• full-index binary diff SHA-256: 86553f62fa929b4ff222fc51df237802005fe996cb83150adc2f64faddf04d0c
• exact NUL-safe inventory: sandbox/dataops/README.md, sandbox/dataops/template.github-actions.yaml, sandbox/dataops/tests/test_template_github_actions.py

Both values exactly match the replacement PASS bindings. Final file SHA-256 values were:

• DataOps workflow aada8e6f...274b3, README 42918e43...6c4e, test 2848d739...f417;
• aws-infra README d8c7cb05...862a, template babce03f...098, test 16285f31...d7a.

Required commands and results

DataOps:

1. npm run test:sponsor-gsi-migrator — exit 0; 64 tests passed, 0 failed/skipped/cancelled/todo; duration 72034.694494 ms.
2. uv run --with pytest python -m pytest -q tests/infra — exit 0; 40 passed in 12.23s.
3. git diff --check b9470340c2837931a7c1c0cb0cb2148b82216cc7...HEAD — exit 0.
4. Because the candidate is deliberately uncommitted and command 3 therefore covers the unchanged committed range, git diff --check HEAD was also run against the actual working-tree candidate — exit 0.

aws-infra:

1. uv run --with pytest python -m pytest sandbox/dataops/tests -q — exit 0; 72 tests passed, 181 subtests passed in 0.83s.
2. sam validate --lint --template-file sandbox/dataops/template.github-actions.yaml — exit 0; valid SAM/CloudFormation template. A telemetry/metadata-disabled invocation also passed independently.
3. git diff --check d370385556344bb6841f88473c12397c326a6b5a...HEAD — exit 0.
4. git diff --check HEAD against the actual uncommitted candidate — exit 0.

Independent workflow and trust verification

• Parsed all 6/6 local workflows that correspond to the six workflows reported active by the GitHub workflow inventory.
• Migration has exactly workflow_dispatch, exact environment dataops-v1-sandbox, exact actor gate, shared dataops-v1-deploy non-cancelling concurrency, exact sandbox region/role shape, and only the migration command.
• All six candidate workflows contain zero dataops-v1-production or other parsed production target references.
• Ordinary deploy workflow SHA-256 is unchanged at 4611d88891fcb3031a94b0140b7238686e6e68feb68824ac7332d1a71180b14c; the accepted SAM command digest test remains 5a6f6391...d270 and passed.
• infra/template.full.yaml, samconfig.toml, migrator, guard, application resources, flags, providers, and runtime/export labeling are outside the exact path inventory and remain unchanged.
• Parsed trust permits exactly two subjects: the existing exact main ref and exact dataops-v1-sandbox environment, under exact aud=sts.amazonaws.com and StringEquals only.
• Independent adversarial evaluation rejected 9 alternate subjects (production/other environment, other branch/tag/PR, other repo/owner, wildcard), 4 alternate/empty audiences, and 8 structural/parameter mutations (StringLike, missing condition, wildcard/production subject, alternate audience, or widened owner/repo/branch parameters).
• The complete template section beginning at Policies: is byte-identical to the base (SHA-256 016205f2...c1e including the marker; independently hashed policy suffix 4ebd256b...edf). Full infrastructure tests also preserved permission fingerprints, action/resource decisions, attachment/inventory counts, and policy-size headroom.
• Both READMEs independently passed an ordered-control check: protected environment proof first, exact trust apply/read-back second, workflow activation third, and no dispatch; missing/invalid partial states fail closed through normal reviewed source flow.

Worktree and external-state isolation

• Each isolated candidate worktree contains only its three assigned modified paths and no untracked candidate path.
• DataOps main checkout remained byte-for-byte clean before and after testing; HEAD and status/diff hashes are unchanged.
• The user-owned dirty aws-infra main checkout remained exactly unchanged before and after testing. Its HEAD, porcelain-status SHA-256 7b6e3466...e8b00, tracked-diff SHA-256 3aa71590...091, cached state, and listed user-owned paths all match the pre-test snapshot.
• Read-only GitHub checks found zero configured environments and zero Sponsor migration workflow runs. This confirms no environment setup or migration dispatch occurred under this source test; those gates remain pending.
• No AWS-backed validation or AWS CLI/API call was made. sam validate --lint was local.
• UI/screenshots: N/A — no UI page or flow changed.

Acceptance criteria in issue order

1. PASS — exact sandbox migration environment; candidate active-workflow inventory has no production target.
2. PASS — manual/main/actor/repository/concurrency/migration-only/fail-closed contract, including full 64-test migration/guard suite.
3. PASS — ordinary deploy/SAM command, application template, full-sandbox, runtime/resources/names/flags/providers unchanged.
4. PASS — exact two-subject/exact-audience trust; all broader and alternate cases rejected.
5. PASS — permissions, attachments, role/session/retention/resources unchanged.
6. PASS — isolated three-path worktrees; both main checkouts untouched.
7. PASS — exact bases, NUL-safe inventories, trees, diff/file hashes, and clean focused diffs reproduced.
8. PASS — DataOps Sponsor and infrastructure coverage passed with unchanged deploy fingerprint.
9. PASS — parsed/adversarial aws-infra coverage, exact fingerprints, quota/count, and no-broadening checks passed.
10. PASS — replacement Architecture PASS is bound to these exact fingerprints and carries fresh Migrate Sponsor CRM GSIs in a protected stage-only workflow #136 review forward.
11. PASS — replacement Security PASS is bound to these exact fingerprints and preserves independent-review/no-bypass/evidence boundaries.
12. PASS — this Tester ran the complete required workflow with exact results; screenshots N/A.
13. PENDING, correct next gate — PM acceptance and bounded current-tracker reconciliation are not Tester-owned.
14. PENDING — no commit is authorized before PM acceptance; future commits must use the issue's Refs forms.
15. PENDING — On-Call source CI follows future pushes; fail-closed Migrate Sponsor CRM GSIs in a protected stage-only workflow #136/Reconcile Sponsor CRM table ownership with CloudFormation #143 behavior must not be called deployment success.
16. PENDING [HUMAN] — effective sandbox OIDC trust apply/read-back has not occurred.
17. PENDING [HUMAN] — protected dataops-v1-sandbox environment has not been configured/read back.
18. PASS at this source gate — no migration/app dispatch, application deploy, provider/Telegram/feature/queue/private-evidence/data action occurred.

The later HUMAN gates and #143 remain blocking exactly as designed. This TEST PASS authorizes no source activation, environment/trust mutation, deployment, or dispatch.

Verdict: TEST PASS for only DataOps tree 38687cbdf297530c5d37fd6509c871dec8a4f7dc and aws-infra tree 081a96837d6d3d998a802e0b4762c629bdd1a733.