Activity

1. alexeygrigorev

   added

   bugSomething is brokenSomething is broken

   needs groomingRaw intake that needs PM groomingRaw intake that needs PM grooming

   infraDeployment and infrastructureDeployment and infrastructure

   testingTests and QATests and QA

   P0Must haveMust have

   migrationImport or migration workImport or migration work

   and removed

   needs groomingRaw intake that needs PM groomingRaw intake that needs PM grooming

   on Aug 2, 2026
2. alexeygrigorev commented on Aug 2, 2026

   

   alexeygrigorev

   on Aug 2, 2026

   MemberAuthor

   More actions

   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.
3. alexeygrigorev commented on Aug 2, 2026

   

   alexeygrigorev

   on Aug 2, 2026

   MemberAuthor

   More actions

   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.
4. alexeygrigorev commented on Aug 2, 2026

   

   alexeygrigorev

   on Aug 2, 2026

   MemberAuthor

   More actions

   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.
5. alexeygrigorev commented on Aug 2, 2026

   

   alexeygrigorev

   on Aug 2, 2026

   MemberAuthor

   More actions

   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.
6. alexeygrigorev commented on Aug 2, 2026

   

   alexeygrigorev

   on Aug 2, 2026

   MemberAuthor

   More actions

   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.
7. alexeygrigorev commented on Aug 2, 2026

   

   alexeygrigorev

   on Aug 2, 2026

   MemberAuthor

   More actions

   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.
8. alexeygrigorev commented on Aug 2, 2026

   

   alexeygrigorev

   on Aug 2, 2026

   MemberAuthor

   More actions

   PM ACCEPT — sandbox-only source and operator handoff accepted

   I reviewed the exact replacement candidates, the replacement Architecture and Security decisions, the full Tester evidence, and the bounded current-tracker reconciliation. I made no file edit, commit, push, AWS call, GitHub-environment/configuration change, workflow dispatch, deployment, provider/data action, or private-evidence inspection. The only external writes in this PM gate were the explicitly required public issue-body routing updates and this acceptance comment.

   Exact accepted source fingerprints

   DataOps:

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

   aws-infra:

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

   I independently reconstructed both trees again, reproduced both diff hashes, and confirmed clean git diff --check results. These are the same bytes covered by the replacement Security PASS, replacement Architecture PASS, and TEST PASS.

   Product acceptance

   • Sandbox is the only active DataOps target in this change. The migration selects exact dataops-v1-sandbox; active workflow parsing found no production target, and no production environment, stack, deployment, migration, provider smoke, or rollout is created or authorized.
   • The ordinary application deployment path, legacy neutral identities, application template/configuration, runtime behavior, and provider configuration remain unchanged.
   • The operator handoff is explicit and monotonic: commit/review source without activation; configure and read back the exact protected sandbox environment; then integrate/apply and read back the exact additive trust; only then activate the accepted workflow. Dispatch remains prohibited.
   • Partial states fail closed. Trust is dormant before workflow activation; missing protection/trust proof blocks activation; premature workflow activation blocks Make sandbox the only active DataOps deployment and rollout target #145 and requires normal reviewed source reversion.
   • Reconcile Sponsor CRM table ownership with CloudFormation #143 remains the independent Sponsor-table ownership blocker for Migrate Sponsor CRM GSIs in a protected stage-only workflow #136. Sandbox naming does not prove ownership or authorize data loss, migration, or deployment. Migrate Sponsor CRM GSIs in a protected stage-only workflow #136 also requires fresh reviews against the post-Make sandbox the only active DataOps deployment and rollout target #145/post-Reconcile Sponsor CRM table ownership with CloudFormation #143 effective boundary before dispatch.
   • Tester completed the full required workflow: DataOps Sponsor suite 64/64, DataOps infra 40/40, aws-infra 72 tests plus 181 subtests, local SAM lint, parsed workflow/trust adversarial checks, exact path/fingerprint checks, and both working-tree diff checks. UI/screenshots are correctly N/A.
   • Read-only PM confirmation still finds zero configured repository environments and zero Sponsor migration workflow runs. The protected environment, effective trust apply/read-back, activation, and dispatch have not occurred.

   Bounded tracker reconciliation

   Current routing and still-unchecked target-specific gates were changed from production to sandbox only where applicable in #30, #41, #71, #113–#115, #120–#122, #124–#127, #129, #131, #134, and #136. #140 now names the separate exact protected sandbox-environment gate while preserving its completed route-A rejection and #143 handoff.

   #108, #119, #128, #137, and already-regroomed sandbox-only #143 were inspected and required no bounded edit. Their current routing was already target-neutral or sandbox-correct. #143 remains unchanged and still blocks #136.

   No checked criterion, historical comment/evidence/fingerprint, generic deployed-runtime meaning, or issue outside the specified set was rewritten. On #145 I checked only the PM-owned acceptance/reconciliation criterion supported by this review. Source commit, On-Call, protected-environment, and effective-trust HUMAN criteria remain unchecked, and the issue remains open.

   Verdict: PM ACCEPT for only the exact two source fingerprints above. Next owner is Software Engineer for the two accepted source commits without activation; subsequent owners must preserve the documented environment → trust → workflow order. This acceptance authorizes no infrastructure or runtime mutation.
9. alexeygrigorev commented on Aug 8, 2026

   

   alexeygrigorev

   on Aug 8, 2026

   MemberAuthor

   More actions

   PM AMENDMENT — REGROOMED to the usual existing main-branch OIDC model

   The user explicitly selected the simple model used by the other projects. #145 is now DataOps-only and agent-ready again.

   Why no extra configuration is needed

   The ordinary DataOps workflow already assumes the sandbox deploy role with an OIDC token whose exact subject is the repository DataTalksClub/dataops on refs/heads/main. The current migration job's environment: dataops-v1-production changes the token subject from that branch subject to an environment subject, which the existing trust correctly does not admit.

   The simple correction is therefore to remove the migration job's environment key entirely. It is not renamed. With no job environment, the migration uses the same existing exact main-branch OIDC trust/role as ordinary DataOps deployment and the other projects. No GitHub environment, additional OIDC subject, aws-infra source change, trust apply, or reviewer/bypass HUMAN gate is needed.

   This deliberately removes independent environment approval. The retained controls are workflow_dispatch only, exact actor alexeygrigorev, the exact repository/main-branch OIDC trust, exact repository/ref/SHA/OIDC/account/region/stack/table runtime checks, shared non-cancelling concurrency, and all accepted #136 fail-closed migration/ownership/state logic.

   Superseded, not passed or deleted

   The earlier protected-environment design and its Architecture, Security, Tester, and PM PASS decisions are historical only. They do not pass the replacement.

   • DataOps tree 38687cbdf297530c5d37fd6509c871dec8a4f7dc, diff f9e7c7df7f416a580c7a6c938dedb27c7e6d222a2980852fdf648afa03aeae2c, and local unpushed commit 672c205eb58c36c3dbf8c6fe1787ec1d2b0cbc86 are superseded.
   • aws-infra tree 081a96837d6d3d998a802e0b4762c629bdd1a733, diff 86553f62fa929b4ff222fc51df237802005fe996cb83150adc2f64faddf04d0c, and local unpushed commit 8cd8b37ea77c7ad47bd2fb0d10b4c53e17fb94d0 are superseded.

   Both local commits remain outside all remote refs. Their branches, worktrees, commits, and historical comments remain preserved. They must not be merged, pushed, cherry-picked, amended, reset, deleted, reused, or applied. In particular, the aws-infra trust commit must never be applied.

   Replacement scope and gates

   The replacement changes only:

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

   It removes the job environment, updates focused documentation/tests, and preserves ordinary deploy/OIDC/SAM bytes plus every #136 runtime safeguard. A fresh clean DataOps worktree from current main must produce a new base/path/tree/diff/file fingerprint. All replacement criteria are unchecked and require fresh Architecture, Security, Tester, and PM decisions before commit.

   There is no aws-infra candidate, cross-repository test/commit, environment→trust activation sequence, or environment HUMAN gate in the amended workflow. #143 still independently blocks #136, and #136 still requires fresh pre-dispatch reviews after #145 and #143. No dispatch or deployment is part of #145.

   I also made only the bounded current-routing corrections needed for consistency:

   • Migrate Sponsor CRM GSIs in a protected stage-only workflow #136 now depends on the DataOps-only no-environment replacement and retains Reconcile Sponsor CRM table ownership with CloudFormation #143 independently;
   • Reconcile missing CloudFormation ownership provenance for Sponsor CRM table #140/Reconcile Sponsor CRM table ownership with CloudFormation #143 state that the unchanged main-branch OIDC choice does not establish Sponsor-table ownership; and
   • Label deployed sandbox runtime and portable exports as sandbox #146 still depends on completed Make sandbox the only active DataOps deployment and rollout target #145 plus Migrate Sponsor CRM GSIs in a protected stage-only workflow #136, but no longer waits for GitHub-environment or extra-trust evidence.

   Labels remain bug, infra, testing, migration, P0; the block graph remains correct. The issue stays open.

   Exact next role: Software Engineer. Create a fresh clean DataOps worktree/branch from current main, implement only the three owned paths without commit, preserve both superseded local branches/worktrees, and return the newly frozen DataOps-only fingerprint for Architecture and Security review.

   This amendment made no file edit, commit, push, AWS call, GitHub environment/configuration change, workflow dispatch, deployment, or runtime/data mutation. Only the authorized public issue-body routing updates and this comment were written.
10. alexeygrigorev commented on Aug 8, 2026

    

    alexeygrigorev

    on Aug 8, 2026

    MemberAuthor

    More actions

    ARCHITECTURE PASS — DataOps-only usual main-branch OIDC candidate

    I independently reviewed only the final frozen uncommitted replacement candidate. I made no source edit, commit, push, AWS call, GitHub environment/configuration change, workflow dispatch, deployment, or private-evidence inspection.

    Exact fingerprint binding

    • worktree: /home/alexey/git/dataops/.tmp/worktrees/issue-145-usual-oidc
    • base/HEAD: b9470340c2837931a7c1c0cb0cb2148b82216cc7
    • independently reconstructed candidate tree: 95c7004538aa64d0e50035c228baf7a47d426a6e
    • full-index binary diff SHA-256: c73484788d04aee7fc17928aeeef83b1582ccc5259936233e1ec9643697c71a7
    • exact paths: .github/workflows/migrate-sponsor-crm-gsis.yml, scripts/deploy/README.md, scripts/deploy/sponsor-crm-gsi-core.test.mjs

    The worktree has exactly those three unstaged modifications, no staged/untracked candidate path, and clean git diff --check.

    OIDC and workflow architecture

    PASS — removal, not rename. The migration job has no environment property. It has no environment URL, environment secret/variable reference, environment approval path, or custom OIDC audience. The candidate does not create or name dataops-v1-sandbox; it removes the misleading dataops-v1-production binding.

    PASS — usual existing trust path. With no job environment, GitHub emits the normal branch-form subject. The unchanged current aws-infra trust source uses exact StringEquals for aud=sts.amazonaws.com and sub=repo:${GitHubOwner}/${GitHubRepo}:ref:refs/heads/${GitHubBranch}; the current DataOps values are DataTalksClub, dataops, and main. The workflow assumes the unchanged exact role ARN arn:aws:iam::817685572750:role/dataops-github-actions-deploy, region eu-west-1, and fixed migration session name. No aws-infra path, trust condition, alternate subject, role permission, or application resource is part of this candidate.

    PASS — coherent credential boundary. workflow_dispatch remains the only trigger and the job-level gate remains exact github.actor == 'alexeygrigorev'. A dispatch on another ref cannot satisfy the exact main-branch AWS trust, so credential acquisition fails. Before the migrator makes its first AWS request, unchanged runtime validation checks exact event, actor, repository, owner, refs/heads/main, SHA shape, run identity, and region. The first bounded AWS read validates exact account/partition/principal; subsequent unchanged pre-mutation checks bind exact stack name/StackId, logical resource, physical table, ARN, TableId, CloudFormation ownership tags, template/schema, and healthy GSI prefix. Every stage revalidates identity and state before execution.

    This is architecturally coherent without a GitHub Actions environment. The deliberate tradeoff is that exact actor alexeygrigorev is the sole manual authorization and there is no independent environment reviewer. That is the explicit user-selected model; it introduces no new credential subject or permission surface relative to ordinary deployment.

    Migration and deployment isolation

    PASS — #136 fail-closed logic unchanged. The core, migrator, and guard runtime files are byte-identical to base. Shared concurrency remains dataops-v1-deploy with cancel-in-progress: false; the final job step remains only the exact staged migration command. There is no SAM build/package/deploy, ordinary app deployment, guard bypass, or workflow chaining in the migration job.

    PASS — production excluded. Parsed-focused coverage requires every active workflow to contain no production target and requires the migration job to have no environment key. The candidate contains no dataops-v1-production workflow target; documentation says #145 authorizes no dispatch and preserves sandbox operational-data handling.

    PASS — ordinary deployment and identities unchanged. .github/workflows/deploy-dataops-v1.yml is byte-identical to base with SHA-256 4611d88891fcb3031a94b0140b7238686e6e68feb68824ac7332d1a71180b14c. infra/template.full.yaml remains fb272bbd...ee5, samconfig.toml remains bd49bdb2...73e, and package files, runtime resources, flags, provider configuration, stack/resource identities, migrator, and guard are unchanged.

    Supersession and downstream gates

    The replacement branch is rooted directly at b947034; superseded DataOps commit 672c205eb58c36c3dbf8c6fe1787ec1d2b0cbc86 is not an ancestor. That commit and superseded aws-infra commit 8cd8b37ea77c7ad47bd2fb0d10b4c53e17fb94d0 remain present in their local worktrees and are contained by zero remote refs. This candidate reuses neither commit and contains no aws-infra change. Earlier #145 PASS comments remain historical only.

    #143 remains the independent Sponsor ownership blocker. The README explicitly prohibits dispatch under #145 and routes any later migration through fresh #136 Architecture, Security, and HUMAN gates after #143. Simple OIDC does not establish ownership, authorize data loss, or authorize migration/application deployment.

    Architecture static review does not replace the required Tester commands. The focused test additions are structurally appropriate: they assert no parsed/source environment key, exact role/session/region shape, no custom audience, ordinary-deploy digest stability, exact runtime repo/ref contract, and alternate repository/ref/SHA failure before AWS calls.

    Verdict: ARCHITECTURE PASS for only tree 95c7004538aa64d0e50035c228baf7a47d426a6e and diff c73484788d04aee7fc17928aeeef83b1582ccc5259936233e1ec9643697c71a7. Advance this exact fingerprint to Security review, then Tester and PM. This PASS authorizes no commit, push, dispatch, deployment, GitHub environment action, AWS mutation, or use of either superseded commit.
11. alexeygrigorev commented on Aug 8, 2026

    

    alexeygrigorev

    on Aug 8, 2026

    MemberAuthor

    More actions

    SECURITY PASS — final frozen DataOps-only usual-OIDC candidate

    I independently reviewed only the final frozen uncommitted candidate in /home/alexey/git/dataops/.tmp/worktrees/issue-145-usual-oidc. I made no source edit, commit, push, AWS call, GitHub environment/configuration change, workflow dispatch, deployment, or private-evidence inspection. Earlier candidate hashes and their historical decisions were not reused.

    Exact fingerprint binding

    • base/HEAD: b9470340c2837931a7c1c0cb0cb2148b82216cc7
    • independently reconstructed candidate tree: 95c7004538aa64d0e50035c228baf7a47d426a6e
    • independently reproduced full-index binary diff SHA-256: c73484788d04aee7fc17928aeeef83b1582ccc5259936233e1ec9643697c71a7
    • exact NUL-safe inventory: .github/workflows/migrate-sponsor-crm-gsis.yml, scripts/deploy/README.md, scripts/deploy/sponsor-crm-gsi-core.test.mjs
    • file SHA-256: workflow e5e64ced853b5ca7a391a9f979c4fd6e50811d5daec5775bd605f8c184384c1f; README 0a82e1e95d1eac7982834501a578fc32fe1dfa1d92441bbc519796a5357e408a; test 94b92919aad80bf85294393894187b1d6f961553e9848dadf27a2ea8f6de3e9c
    • git diff --check b9470340c2837931a7c1c0cb0cb2148b82216cc7 passed.

    Security findings

    • The only executable workflow change removes the obsolete environment: dataops-v1-production line. It adds no trigger, principal, trust subject, permission, secret, variable, input, audience override, target selector, or production reference.
    • Parsed migration shape remains exactly workflow_dispatch, exact job actor alexeygrigorev, contents: read plus job-local id-token: write, shared dataops-v1-deploy concurrency with cancel-in-progress: false, fixed region eu-west-1, fixed role arn:aws:iam::817685572750:role/dataops-github-actions-deploy, fixed session name dataops-v1-sponsor-gsi-migration, and the single exact migration command. The ordinary deploy workflow is byte-identical to base (4611d888...b14c). All active workflow source is free of a production target.
    • Canonical aws-infra at accepted base d370385556344bb6841f88473c12397c326a6b5a admits only exact aud=sts.amazonaws.com and exact sub=repo:DataTalksClub/dataops:ref:refs/heads/main under StringEquals. This candidate contains no aws-infra path and changes neither trust nor deploy-role policy. Removing the job environment therefore makes this workflow use an already-admitted principal; it does not add a principal class or broaden IAM permissions.
    • The actor job condition is evaluated before credential configuration. The unchanged migrator then checks exact owner/repository/main ref, lowercase 40-hex GITHUB_SHA, dispatch event, actor, workspace, and both AWS region variables before its first AWS CLI call. The existing OIDC trust independently rejects alternate repository/ref subjects before role assumption. Runtime caller validation pins account 817685572750 and the exact deploy role before stack/table reads.
    • Target and mutation boundaries remain unchanged: fixed account, partition/region, stack dataops-v1, logical resource DataOpsSponsorCrmTable, physical table dataops-v1-sponsor-crm, stack ARN, table ARN/TableId and ownership-tag checks, exact checked-in template arguments, migration-only command, and the full Migrate Sponsor CRM GSIs in a protected stage-only workflow #136 fail-closed state machine. infra/template.full.yaml, samconfig.toml, migrator/core/guard runtime, and the ordinary deploy workflow are byte-identical to base.
    • Focused adversarial run passed 6/6 selected tests, including alternate actor, owner/repository, dev/tag/PR ref, and malformed SHA. Every new source mismatch case recorded zero migrator AWS calls; workflow parsing also proved no environment/secrets/vars/audience override and no production target.
    • Reconcile Sponsor CRM table ownership with CloudFormation #143 remains OPEN/blocked on HUMAN ownership classification and explicitly authorizes no AWS call, workflow dispatch, deployment, or mutation. Migrate Sponsor CRM GSIs in a protected stage-only workflow #136 remains OPEN/blocked on both accepted Make sandbox the only active DataOps deployment and rollout target #145 integration/source CI and Reconcile Sponsor CRM table ownership with CloudFormation #143, then requires fresh Architecture/Security plus HUMAN pre-dispatch approval. Make sandbox the only active DataOps deployment and rollout target #145 itself authorizes no dispatch or AWS action.
    • Superseded DataOps commit 672c205eb58c36c3dbf8c6fe1787ec1d2b0cbc86 and aws-infra commit 8cd8b37ea77c7ad47bd2fb0d10b4c53e17fb94d0 still exist in their preserved local worktrees/branches, occur in no remote-tracking ref, and are not ancestors of either accepted base. The final candidate neither layers on nor uses them.

    Residual-risk disposition

    Accepted for this user-selected simple model: there is no independent GitHub-environment reviewer or second-person approval, and the issue dependency/HUMAN dispatch gates are process controls rather than a technical GitHub dependency lock. A compromise of the approved actor/repository main-branch authority, or an unauthorized manual dispatch that satisfies those identities, therefore has no environment-review backstop. Also, SHA is validated and bound as the actual workflow commit provenance rather than compared with a source-hardcoded allowlist; the HUMAN #136 gate must approve the eventual integrated SHA. These are the explicit simplicity tradeoffs recorded by the user, not new trust or permission expansion in this diff.

    No source change here authorizes a dispatch or AWS action. It only repairs the source identity mismatch so that a later separately authorized #136 dispatch can use the unchanged usual main-branch OIDC path.

    Verdict: SECURITY PASS for exactly tree 95c7004538aa64d0e50035c228baf7a47d426a6e / diff c73484788d04aee7fc17928aeeef83b1582ccc5259936233e1ec9643697c71a7. Any byte, trust/policy, dependency, or dispatch-plan change requires fresh Security review.
12. alexeygrigorev commented on Aug 8, 2026

    

    alexeygrigorev

    on Aug 8, 2026

    Last edited by alexeygrigorev

    MemberAuthor

    More actions

    TEST PASS — final frozen DataOps-only usual main-branch OIDC candidate

    I independently tested only the frozen uncommitted candidate in /home/alexey/git/dataops/.tmp/worktrees/issue-145-usual-oidc. I made no file edit, commit, push, AWS call, workflow dispatch, deployment, GitHub environment/configuration change, private-evidence inspection, or data/provider action. UI/screenshots are N/A because the exact diff contains only workflow, public deployment README, and focused test source.

    Exact candidate binding

    • base/HEAD/origin-main: b9470340c2837931a7c1c0cb0cb2148b82216cc7
    • independently reconstructed candidate tree: 95c7004538aa64d0e50035c228baf7a47d426a6e
    • full-index binary diff SHA-256: c73484788d04aee7fc17928aeeef83b1582ccc5259936233e1ec9643697c71a7
    • NUL-safe inventory, exactly 3 unstaged paths and zero staged/untracked paths:
      • .github/workflows/migrate-sponsor-crm-gsis.yml
      • scripts/deploy/README.md
      • scripts/deploy/sponsor-crm-gsi-core.test.mjs
    • file SHA-256 respectively: e5e64ced853b5ca7a391a9f979c4fd6e50811d5daec5775bd605f8c184384c1f, 0a82e1e95d1eac7982834501a578fc32fe1dfa1d92441bbc519796a5357e408a, 94b92919aad80bf85294393894187b1d6f961553e9848dadf27a2ea8f6de3e9c
    • isolated linked-worktree git dir: /home/alexey/git/dataops/.git/worktrees/issue-145-usual-oidc; main checkout remained clean.

    Commands and results

    • npm run test:sponsor-gsi-migrator — exit 0; 65 tests, 65 pass, 0 fail/skipped/cancelled/todo.
    • uv run --with pytest python -m pytest -q tests/infra — exit 0; 40 passed.
    • git diff --check b9470340c2837931a7c1c0cb0cb2148b82216cc7 — exit 0; no output.
    • git diff --full-index --binary b9470340c2837931a7c1c0cb0cb2148b82216cc7 | sha256sum — exit 0; reproduced c734847...71a7.
    • git diff --name-only -z b9470340c2837931a7c1c0cb0cb2148b82216cc7 plus a read-only python - <<'PY' Git-tree reconstruction — exit 0; exact 3-path inventory and tree 95c700...a6e.
    • node --input-type=module - <<'NODE' with independent js-yaml JSON-schema assertions — exit 0; parsed all 6 active workflows: assistant-ci.yml, deploy-dataops-v1.yml, migrate-sponsor-crm-gsis.yml, typefully-analyzer.yml, validate-dataops-content.yml, validate-planning-docs.yml.
    • Seven isolated invalid-runtime invocations of /home/alexey/.nvm/versions/node/v24.13.1/bin/node scripts/deploy/sponsor-crm-gsi-migrator.mjs migrate infra/template.full.yaml infra/template.full.yaml, using env -i PATH=/nonexistent and overriding actor, repository, owner, dev ref, tag ref, PR ref, or SHA — each exit 1 with the expected pre-AWS fail-closed category; the aggregate assertion command exited 0. PATH=/nonexistent made an AWS call impossible even if a check regressed.
    • sha256sum plus byte comparison to git show b947034...:<path> — exit 0; protected-file results below.
    • git for-each-ref --contains=<superseded> refs/remotes in each repo and git merge-base --is-ancestor against each accepted base — exit 0 for the aggregate assertions; zero remote refs contain either superseded commit and neither is an ancestor of the accepted base.
    • Read-only gh api repos/DataTalksClub/dataops/environments and gh run list --workflow migrate-sponsor-crm-gsis.yml --event workflow_dispatch — exit 0; 0 environments, 0 migration dispatch runs.

    Independent workflow and protected-byte evidence

    Parsed migration shape is exact:

    • only trigger workflow_dispatch, with no caller input/target selector;
    • job gate github.actor == 'alexeygrigorev';
    • no parsed/source environment, environment URL, secrets.*, vars.*, or credential audience override;
    • permissions exactly contents: read and job-local id-token: write;
    • shared concurrency dataops-v1-deploy, cancel-in-progress: false;
    • region eu-west-1, role arn:aws:iam::817685572750:role/dataops-github-actions-deploy, session dataops-v1-sponsor-gsi-migration;
    • after credential setup, the sole final step is exactly set -euo pipefail plus node scripts/deploy/sponsor-crm-gsi-migrator.mjs migrate infra/template.full.yaml infra/template.full.yaml;
    • no active workflow source or parsed value contains a production target or dataops-v1-production.

    The unchanged runtime validates exact repository DataTalksClub/dataops, owner, refs/heads/main, lower-case 40-hex GITHUB_SHA, dispatch event, actor, run identity, and both region variables before its first AWS request. CONTRACT remains exact account 817685572750, region, stack dataops-v1, logical ID DataOpsSponsorCrmTable, and physical table dataops-v1-sponsor-crm. The seven adversarial cases all stopped before AWS.

    At accepted aws-infra base d370385556344bb6841f88473c12397c326a6b5a, the unchanged trust is exact StringEquals for aud=sts.amazonaws.com and sub=repo:DataTalksClub/dataops:ref:refs/heads/main; defaults remain the exact role/stack/region above. There is no aws-infra candidate or trust/policy change.

    Protected working bytes equal base:

    • ordinary deploy workflow: 4611d88891fcb3031a94b0140b7238686e6e68feb68824ac7332d1a71180b14c
    • ordinary sam deploy command: 5a6f6391d8be4c5b6219e5e9c94d7249d312ccab1d743b4d7bf20cb6d082d270
    • infra/template.full.yaml: fb272bbddbde1a41cb2b5ae92cf0923baa03815a517df143119731fee2ef8ee5
    • samconfig.toml: bd49bdb2eefeb1342b393531a90dcbb4ebf4a368f427d63de3bde776dfea473e (full-sandbox remains present)
    • core runtime: fe5a2944b8da2721e8a1df061b1ac283ccea2e6ce35df20920229e5c4fc94b10
    • migrator runtime: e5b076b75ee03fa47aa263bba6cf766b847045805dab35f7a13c36c6a049bd35
    • guard runtime: ca2ccdfec35fdfeb114800b5146d2e9c057b16132ab861cb6ea2ce6195923aaa
    • package.json: 4102f3e021b64d687418783d981dd6a7fd3eeadd326070e56ddfa5e19cfc3df8
    • package-lock.json: 47f803105ef2e5148e082a295a342b66b97e8386dcbbc736c2384f182d5e5e12

    The exact three-path inventory proves every other non-owned path, including runtime resources, flags, provider configuration, identities, SAM/template/config, and ordinary deployment, is unchanged.

    Acceptance criteria in issue order

    1. PASS — migration job has no environment key/dependency/approval path.
    2. PASS — existing exact main-branch OIDC trust/role is used; no environment subject, trust/policy, aws-infra, or apply change.
    3. PASS — exact manual actor/repository/main/SHA/OIDC/account/region/stack/table contract, non-cancelling concurrency, migration-only command, and unchanged Migrate Sponsor CRM GSIs in a protected stage-only workflow #136 fail-closed runtime are proven by parsing, protected hashes, 65/65 suite, and adversarial checks.
    4. PASS — all 6 active workflows are free of a production target.
    5. PASS — ordinary deploy/SAM command, template, full-sandbox, runtime/resources/names/flags/providers are byte-identical.
    6. PASS — fresh base, exact paths/tree/diff/file fingerprints reproduced; worktree is isolated and clean outside the 3 unstaged owned paths.
    7. PASS — superseded DataOps 672c205... remains on local branch/worktree issue-145-sandbox-boundary/.tmp/worktrees/issue-145; superseded aws-infra 8cd8b37... remains on issue-145-sandbox-oidc/aws-infra-worktrees/issue-145-sandbox-oidc. Both have zero containing remote refs, neither is an accepted-base ancestor, and neither is reused.
    8. PASS — focused tests parse every active workflow, pin no environment/manual actor/OIDC/concurrency/migration-only/no-production and ordinary deploy/SAM digests; independent parsing confirms them.
    9. PASS (prior gate) — final Architecture PASS is bound to this exact tree/diff.
    10. PASS (prior gate) — final Security PASS is bound to this exact tree/diff.
    11. PASS — complete required Tester verification is recorded above; screenshots N/A.
    12. NEXT GATE, not claimed — PM acceptance must follow this Tester result and confirm the simplified operator flow/supersession.
    13. FUTURE RELEASE STEP, not claimed — no commit exists yet; SWE must commit only after PM acceptance, with no aws-infra commit.
    14. FUTURE RELEASE STEP, not claimed — orchestrator merge/push and On-Call source-CI/no-dispatch verification remain pending.
    15. PASS for this source gate — no prohibited environment/AWS/workflow/deploy/provider/data/private-evidence action occurred; read-only GitHub checks show zero environments and zero migration dispatch runs.

    Routing also remains fail-closed: #136 is OPEN/blocked on accepted #145 integration/source CI with no dispatch and independently on #143, then requires fresh Architecture/Security before HUMAN dispatch. #143 is OPEN/blocked on HUMAN ownership/loss classification and authorizes no AWS call, dispatch, deployment, or mutation. Simple OIDC and sandbox naming establish neither Sponsor ownership nor dispatch authority.

    Verdict: TEST PASS for only tree 95c7004538aa64d0e50035c228baf7a47d426a6e / diff c73484788d04aee7fc17928aeeef83b1582ccc5259936233e1ec9643697c71a7. Any byte, trust/policy, dependency, or dispatch-plan change requires fresh Tester review.
13. alexeygrigorev commented on Aug 8, 2026

    

    alexeygrigorev

    on Aug 8, 2026

    MemberAuthor

    More actions

    PM ACCEPT — final DataOps-only usual-OIDC source candidate

    I reviewed the user-selected simplified operator outcome, the exact frozen source, the Architecture PASS, Security PASS, and TEST PASS.

    Exact accepted fingerprint

    • base: b9470340c2837931a7c1c0cb0cb2148b82216cc7
    • candidate tree: 95c7004538aa64d0e50035c228baf7a47d426a6e
    • full-index binary diff SHA-256: c73484788d04aee7fc17928aeeef83b1582ccc5259936233e1ec9643697c71a7
    • exact paths: .github/workflows/migrate-sponsor-crm-gsis.yml, scripts/deploy/README.md, scripts/deploy/sponsor-crm-gsi-core.test.mjs

    I independently reconstructed the same tree and diff again immediately before acceptance. The worktree still contains exactly those three unstaged paths and passes git diff --check.

    Product acceptance

    • The implementation does exactly what the user requested: it removes the misleading migration environment binding rather than renaming it, so the job uses the usual existing exact DataTalksClub/dataops main-branch OIDC role/trust path.
    • It creates no GitHub environment, extra environment OIDC subject, aws-infra source/apply, trust/permission change, production target, or alternate deployment path.
    • The simplified authorization is clear to the operator: manual workflow_dispatch, exact actor alexeygrigorev, exact repository/main OIDC trust, unchanged repository/ref/SHA/account/region/stack/table runtime validation, shared non-cancelling concurrency, and the complete unchanged Migrate Sponsor CRM GSIs in a protected stage-only workflow #136 fail-closed migration state machine.
    • The accepted simplicity tradeoff is explicit: there is no independent GitHub-environment reviewer. That is the user-selected model, not an accidental omission. Make sandbox the only active DataOps deployment and rollout target #145 still authorizes no dispatch.
    • Ordinary deploy, exact SAM command, infra/template.full.yaml, samconfig.toml/full-sandbox, runtime resources, identities, flags, provider configuration, migrator, guard, and every non-owned path remain unchanged.
    • The focused README accurately says Reconcile Sponsor CRM table ownership with CloudFormation #143 must establish Sponsor-table ownership and Migrate Sponsor CRM GSIs in a protected stage-only workflow #136 must pass fresh Architecture, Security, and HUMAN pre-dispatch gates before migration or the following normal application deployment.

    Verification and preservation

    Tester passed the full required source gate: Sponsor migration suite 65/65, infra suite 40/40, all six active workflow parses, seven isolated invalid-identity/ref/SHA fail-closed cases, exact protected-byte comparisons, fingerprint reconstruction, and clean diff checks. UI/screenshots are correctly N/A.

    Read-only evidence records zero configured GitHub environments and zero Sponsor migration dispatch runs. No AWS call, trust/permission mutation, workflow dispatch, application deploy, provider/data action, private-evidence inspection, or runtime mutation occurred.

    Superseded DataOps commit 672c205eb58c36c3dbf8c6fe1787ec1d2b0cbc86 and superseded aws-infra commit 8cd8b37ea77c7ad47bd2fb0d10b4c53e17fb94d0 remain preserved in their local branches/worktrees, occur in zero remote refs, are not ancestors of the accepted base, and were not reused. Their earlier PASS comments remain historical only.

    Tracker and release handoff

    Sandbox routing was already reconciled and remains correct:

    • Migrate Sponsor CRM GSIs in a protected stage-only workflow #136 is OPEN and blocked on accepted Make sandbox the only active DataOps deployment and rollout target #145 integration/source CI with no dispatch, independently on Reconcile Sponsor CRM table ownership with CloudFormation #143, and then on fresh Architecture/Security plus HUMAN pre-dispatch approval.
    • Reconcile Sponsor CRM table ownership with CloudFormation #143 is OPEN and blocked on HUMAN ownership/loss classification; usual OIDC establishes no ownership or mutation authority.
    • Label deployed sandbox runtime and portable exports as sandbox #146 remains OPEN and blocked on completed Make sandbox the only active DataOps deployment and rollout target #145 plus the full Migrate Sponsor CRM GSIs in a protected stage-only workflow #136 sandbox migration and ordinary deployment, with no stale environment/trust prerequisite.

    I checked only the source, role-review, Tester, PM, preservation, and no-external-action criteria supported by the evidence. The Software Engineer commit and orchestrator merge/push plus On-Call source-CI/no-dispatch criteria remain unchecked. Issue #145 remains open.

    Verdict: PM ACCEPT for only tree 95c7004538aa64d0e50035c228baf7a47d426a6e / diff c73484788d04aee7fc17928aeeef83b1582ccc5259936233e1ec9643697c71a7. Exact next role: Software Engineer commits only this accepted DataOps candidate with Closes #145; no aws-infra commit or external action. Orchestrator and On-Call follow afterward, still with no dispatch under #145.
14. alexeygrigorev

    closed this as completedin 70caa01on Aug 8, 2026
15. alexeygrigorev

    added a commit that references this issue on Aug 8, 2026

    Merge issue-145-usual-oidc: Use usual OIDC for sandbox migration (#145)

    d0c2b50
16. alexeygrigorev commented on Aug 8, 2026

    

    alexeygrigorev

    on Aug 8, 2026

    MemberAuthor

    More actions

    ON-CALL BLOCK — #145 source checks pass; normal deployment fails closed at the independent Sponsor ownership guard

    I monitored every GitHub Actions run automatically associated with pushed merge SHA d0c2b5033d3272c7eda9db61868cd106742e2bb0 to terminal state. I did not dispatch or rerun any workflow, call AWS, change a GitHub environment or IAM, edit source, or bypass a guard.

    Exact integration binding

    • merge SHA: d0c2b5033d3272c7eda9db61868cd106742e2bb0
    • accepted commit: 70caa018620c0e603641d8559270e704950eb665
    • merge tree and accepted-commit tree: 95c7004538aa64d0e50035c228baf7a47d426a6e (the exact Architecture/Security/Tester/PM-accepted tree)
    • exact integrated paths: .github/workflows/migrate-sponsor-crm-gsis.yml, scripts/deploy/README.md, and scripts/deploy/sponsor-crm-gsi-core.test.mjs
    • local HEAD, origin/main, and the Actions run head all resolve to the exact merge SHA.

    Automatically triggered run

    The Actions API reports exactly one run for this SHA:

    • Deploy DataOps V1 Lambda run 31248327417 — event push, terminal conclusion failure.
      • Check DataOps v1 app job 93080501403 — success. Backend tests, the Sponsor CRM GSI deployment-gate suite, backend typecheck/build, Playwright E2E, SAM validation, and SAM artifact build all passed. The failure-only artifact upload was correctly skipped.
      • Deploy DataOps v1 app job 93081298929 — failure, exactly at Guard Sponsor CRM indexes before any deployment build with Sponsor CRM deployment guard failed closed: guard-cloudformation-table-stack-id-absent and exit 1.
      • The later deploy-job steps — SAM artifact build, stack deployment, runtime seeding, and deployed-backend smoke test — were all skipped. Therefore this run did not deploy the application.

    The planning-doc and content-validation workflows did not trigger, as expected: none of the exact three integrated paths matches their push path filters. Their absence is not a missing run; the SHA-wide Actions query shows exactly the single normal deploy workflow above. The deploy workflow supplied the applicable source/test/SAM checks, and its entire checks job passed.

    No-dispatch evidence

    • Migrate Sponsor CRM GSIs Actions API readback: total_count: 0 — zero migration runs of any event type and therefore zero migration dispatches.
    • The sole run for the merge SHA has event push; there was no manual application workflow dispatch or rerun.
    • No migration command ran. No application deploy, seed, or smoke step ran after the ownership guard.

    Classification and routing

    This is not a #145 source/CI regression: the exact accepted tree is integrated and every source/test/build check passed. It is also not deployment success. The automatic normal deploy correctly reached and honored the pre-existing fail-closed Sponsor ownership boundary.

    Issue #145 is currently CLOSED (completed) via Closes #145. Keep it closed for the accepted usual-OIDC source correction; do not repair or bypass this failure under #145 and do not rerun/deploy manually.

    Next routing remains:

    1. #143 is OPEN and owns the HUMAN classification/ownership decision for the existing sandbox Sponsor table.
    2. #136 is OPEN. It may record Make sandbox the only active DataOps deployment and rollout target #145 integration/source-check completion with no dispatch, but remains blocked on the accepted Reconcile Sponsor CRM table ownership with CloudFormation #143 outcome and then its fresh Architecture, Security, and HUMAN pre-dispatch gates.
    3. Only that separately authorized sequence can permit a future Sponsor migration and subsequent normal application deployment. No Software Engineer fix is routed from this Make sandbox the only active DataOps deployment and rollout target #145 run.

    Verdict: ON-CALL BLOCK — #145 source CI passed and no migration was dispatched, but the automatic application deployment did not occur because the independent #143/#136 Sponsor ownership guard failed closed as designed.
17. alexeygrigorev commented on Aug 8, 2026

    

    alexeygrigorev

    on Aug 8, 2026

    MemberAuthor

    More actions

    PM POST-ON-CALL RECONCILIATION — source shipped; deployment correctly blocked

    #145 is complete for its accepted source correction at merge SHA d0c2b5033d3272c7eda9db61868cd106742e2bb0 (tree 95c7004538aa64d0e50035c228baf7a47d426a6e). The applicable source/test/build checks passed and zero migration runs occurred.

    The automatic normal deployment is not accepted as deployment success. It failed closed at the pre-existing guard-cloudformation-table-stack-id-absent ownership guard; SAM deploy, seed, and deployed smoke were skipped. Do not rerun, bypass, or repair that boundary under closed #145.

    #145 remains CLOSED/COMPLETED. All previously unchecked release/On-Call criteria remain unchanged as historical checklist state. Current ownership routing continues in #143 and #136.
18. alexeygrigorev

    added 2 commits that reference this issue on Aug 14, 2026

    Use usual OIDC for sandbox migration

    ...

    This issue will close once commit 2214a2b is merged into the 'main' branch.

    2214a2b

    Merge issue-145-usual-oidc: Use usual OIDC for sandbox migration (#145)

    This issue will close once commit 14b6fa2 is merged into the 'main' branch.

    14b6fa2