Skip to content

THOTH-ASYNC-01-ADR-01: approve ADR-0012 shared async architecture - #960

Open
ja573 wants to merge 27 commits into
feature/workerfrom
feature/async/adr-0012
Open

ja573 wants to merge 27 commits into
feature/workerfrom
feature/async/adr-0012

Conversation

@ja573

@ja573 ja573 commented Sep 30, 2026

Copy link
Copy Markdown
Member

THOTH-ASYNC-01-ADR-01

Programme: #957 THOTH-ASYNC-01
Owning task: #958 THOTH-ASYNC-01-ADR-01
Risk: CRITICAL

Exact identity

target: develop @ 923545d5c9028bc04c40e38efeb7de674efed3fd
source: feature/async/adr-0012
head: bd5223deee44b465dd860ff96b75d81ad41cbf2d

CTO-approved architecture content head:

631e28d1f05495f24ce88369d4557f1033f970b3

Final reviewed approval-state head:

bd5223deee44b465dd860ff96b75d81ad41cbf2d

Final independent CRITICAL review:

APPROVED
#958 comment 5914564111

ADR-0012 is APPROVED, but it is not repository-authoritative until this exact approved content is merged into develop.

Cumulative PR footprint

Exactly six paths:

CHANGELOG.md
docs/engineering/ai-delivery/implementation-reports/THOTH-ASYNC-01-ADR-01-implementation-report.md
docs/engineering/decisions/ADR-0008-machine-roles-and-durable-job-primitives.md
docs/engineering/decisions/ADR-0010-staff-operations-console.md
docs/engineering/decisions/ADR-0012-shared-asynchronous-event-and-job-execution.md
docs/engineering/decisions/decision-register.md

The ADR-0008 and ADR-0010 changes are limited to the separately authorized durable partial-supersession metadata reconciliation already defined by approved ADR-0012. All unaffected machine-role, least-privilege, SUPERUSER, Staff Operations, ServiceOperation, desired/execution/observed-state, attention/reconciliation and staff-command controls remain binding.

Scope and effects

This PR contains architecture and engineering-control documentation only.

It includes no:

  • runtime implementation;
  • database migration or schema/API change;
  • IAM/provider/runtime action;
  • worker deployment;
  • BE-04/DIS-02 activation;
  • Hosting implementation;
  • external write;
  • release;
  • production deployment or activation.

Opening this PR may trigger the repository's normal automatic PR CI/checks. No manual CI dispatch or rerun is authorized.

Remaining gates

This draft PR does not authorize merge.

Before merge:

  1. automatic PR CI/checks must complete successfully;
  2. the PR must remain at exact reviewed head bd5223deee44b465dd860ff96b75d81ad41cbf2d;
  3. any required PR-stage review/control must remain satisfied;
  4. CRITICAL merge requires separate exact-head CTO merge authorization.

Any source commit invalidates the existing independent approval.

Tracks #957 and #958.

@chatgpt-codex-connector

chatgpt-codex-connector Bot commented Sep 30, 2026 •

Copy link
Copy Markdown

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review Status Commit Review trigger
📝 Code Review ✅ Completed 2026-10-01T15:53:10.923637Z b4670b8 New commits
ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: bd5223deee

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment on lines +25 to +30
Exactly four repository paths are used:

1. `docs/engineering/decisions/ADR-0012-shared-asynchronous-event-and-job-execution.md`;
2. `docs/engineering/decisions/decision-register.md`;
3. `CHANGELOG.md`;
4. this implementation report.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Update the report to cover the approval-state commit

The report claims that exactly four paths were used, but this commit changes six, including ADR-0008 and ADR-0010; it also later says ADR-0012 remains PROPOSED and lists approval/reconciliation as future gates even though this commit marks it APPROVED. This leaves the CRITICAL-task evidence unable to demonstrate the actual write budget, final head, checks, and approval-state work, so replace the authoring-era assertions with the final six-file commit state and validation results.

AGENTS.md reference: AGENTS.md:L437-L445

Useful? React with 👍 / 👎.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CTO/control ruling: NOT CLOSED. The stale authoring-era assertions were corrected, but the implementation report still lacks exact final-candidate validation commands/results and durable approval-state history. It will be remediated within the authorized report-only portion of the current three-path correction. This reply does not resolve the thread.

Comment on lines +1330 to +1331
8. Every event-route record maps to exactly one job; many route records may map
to one job only under an explicit not-yet-started coalescing rule.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Exempt terminal route dispositions from the job mapping invariant

When an eligible route can no longer be materialized safely, section 3.2 explicitly requires a terminal (event_id, route_key) disposition recording that no job was materialized. This invariant instead requires every event-route record to map to exactly one job, so an implementation cannot represent that recovery path while satisfying the approved invariants—for example, a non-null job foreign key would force creation of a fictitious job. Qualify this mapping rule to apply only to successfully materialized dispositions, or define the distinct terminal-disposition representation.

Useful? React with 👍 / 👎.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CTO/control ruling: VALID-BLOCKING. ADR-0012 section 3.2 already selects terminal non-materialized route dispositions, so the contradiction in section 3.5 / invariant 8 is judged a factual clarification rather than a new architecture decision. The correction will make one disposition per (event_id, route_key) authoritative, with materialized dispositions pointing to exactly one job and terminal non-materialized dispositions pointing to no job under the same uniqueness boundary. This reply does not resolve the thread.

@ja573
ja573 changed the base branch from develop to feature/worker September 30, 2026 20:10

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 7f7e62824e

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment on lines +1093 to +1095
The implementation programme must inspect all repository-authoritative contract
consumers again immediately before retirement; this list is not permission to
assume no additional consumer exists.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Assess every verified GraphQL consumer before approval

Deferring the consumer audit until retirement leaves this approved breaking-contract plan without the required impact assessment for the other verified GraphQL consumers in docs/engineering/repository-map/contracts.md, including thoth-pyramid, the standalone thoth-client, both Metrics clients, Baboon, and the internal export client. Because Phase C explicitly removes released GraphQL fields/types, each known consumer must either receive downstream work or have compatibility recorded before the architecture is approved, rather than being discovered immediately before removal.

AGENTS.md reference: AGENTS.md:L226-L234

Useful? React with 👍 / 👎.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CTO/control ruling: NOT-BLOCKING. Independent live consumer verification found BE-04 identifier usage requiring downstream migration only in thoth-app and thoth-dissemination; the other verified GraphQL consumers were unaffected by this specific retiring surface. That per-consumer evidence will be made durable in the corrected implementation report. This reply does not resolve the thread.

Comment on lines +533 to +537
- the final candidate against `feature/worker` is required to remain exactly
the cumulative six-path ADR task footprint;
- no runtime test result is claimed by this documentation/control-only task;
- live candidate head, CI, review and merge evidence belongs in GitHub #957/#958
rather than in a self-invalidating committed status line.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Record the reconciled head and exact validation results

The fresh evidence in this revision is that the report now lists the six-path footprint, but this final section still describes the candidate as merely “required” and delegates its head and validation evidence to GitHub. The report never identifies f7e666fe2d9e93b2363c332898a66b0da81df067 as the reconciled head or records an exact validation command and concise result, so the CRITICAL review artifact cannot demonstrate which six-file content was actually checked.

AGENTS.md reference: AGENTS.md:L437-L445

Useful? React with 👍 / 👎.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CTO/control ruling: VALID-BLOCKING as to the missing exact validation evidence. The SHA quoted in the Codex text is not the live PR head, but the underlying evidence requirement is valid: the corrected report must record literal final-candidate validation commands/results and CI applicability. It must not embed the containing commit SHA. This reply does not resolve the thread.

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 227057cae8

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Original workflow: STANDARD; delivery topology later amended to PROGRAMME_INTEGRATION
Original authorized base: develop @ 923545d5c9028bc04c40e38efeb7de674efed3fd
Programme integration base: feature/worker @ 345a7a04131e7c0539f7518c6ea457fa5cb6a462
Task branch: feature/async/adr-0012

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Move the task onto the governed programme-slice branch

Once the report classifies delivery as PROGRAMME_INTEGRATION and targets feature/worker, retaining the standard-workflow branch feature/async/adr-0012 conflicts with the selected feature/worker -> feature/worker--<slice> -> feature/worker topology. This leaves the CRITICAL slice’s durable identity inconsistent with the programme namespace; HOLD and obtain corrected task authorization for a governed feature/worker--<slice> branch rather than treating PR retargeting as sufficient.

AGENTS.md reference: AGENTS.md:L108-L115

Useful? React with 👍 / 👎.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CTO/control disposition: NOT-BLOCKING under the task's explicit transitional exception.

This ADR task predates the programme-integration branch topology. #958 comment 5915346410 explicitly permits the existing feature/async/adr-0012 branch to be retained for this task instead of recreating it as feature/worker--adr-0012, subject to the later compatibility controls. #958 comments 5918809879 and 5918894151 then explicitly authorize the retarget and compatibility reconciliation on that same pre-topology branch. Subsequent THOTH-ASYNC slices remain subject to the governed sibling branch form.

This reply does not resolve the thread.

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: b4670b8b7c

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment on lines +250 to +254
strong serialized database mechanism, that an event captures inside its
creating transaction and a route records when it is activated or deactivated.
An event is eligible exactly when its captured routing generation is at or after
the route's activation generation and, when a deactivation generation exists,
strictly before that deactivation generation.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Represent repeated route activation intervals

When an active route is temporarily deactivated for the rollback procedure specified later in this ADR and then reactivated after emission-capable binaries return, this single activation/deactivation pair cannot represent the required eligibility set [first activation, deactivation) ∪ [reactivation, ...). Overwriting either generation retroactively changes which historical events are owed, while assigning a new route_key conflicts with the promised stable identity and can rematerialize old events under a fresh uniqueness key. Define an append-only activation-epoch/route-incarnation model, including how (event_id, route_key) uniqueness behaves across reactivation, before implementation.

AGENTS.md reference: AGENTS.md:L361-L361

Useful? React with 👍 / 👎.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CTO/control disposition: VALID-BLOCKING.

The exact-head source confirms the problem. ADR-0012 gives each durable route one stable route_key, one activation boundary and one optional deactivation boundary, with eligibility defined as a single interval [activation_generation, deactivation_generation). The same ADR also explicitly permits rollback below an active route's emission floor by deactivating the route before old writers resume.

After forward recovery, the architecture provides no durable representation for the same logical route becoming eligible again while preserving historical eligibility and the promised (event_id, route_key) identity. Overwriting the original boundaries would rewrite historical eligibility; inventing a new route key would introduce a new identity model that the ADR does not define.

This therefore requires an explicit bounded ADR-0012 architecture correction defining repeated activation semantics (for example append-only activation epochs under the stable logical route identity, or another explicitly selected equivalent) and the corresponding uniqueness/backfill/retirement/test semantics.

This reply does not resolve the thread and authorizes no source mutation, implementation, merge or runtime action.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant