APP-04 - Hide deprecated Figshare and Cambridge distribution options

[ja573]

APP-04 - Hide deprecated Figshare and Cambridge distribution options

Status

INTEGRATION-VERIFICATION SPECIFICATION CANDIDATE - REVISED AFTER CONTROL PRE-REVIEW AND LIVE BASELINE REBIND - AWAITING INDEPENDENT REVIEW AND CTO APPROVAL

Source implementation: NOT EXPECTED / NOT AUTHORIZED

Current gate: HOLD - wait for approved/merged BE-05, DIS-03 runtime retirement and controlled assignment reconciliation; then verify the existing app generically against the exact deployed backend contract.

No app source, branch, PR, browser/runtime, deployment or production mutation is authorized by this specification revision.

1. Task identity

• Programme: Publisher Services and Distribution Configuration
• Parent programme issue: thoth-pub/thoth#765
• Task ID: APP-04
• Repository: thoth-pub/thoth-app
• Programme stage: application compatibility / platform-retirement presentation
• Workflow: verification-only; no source workflow expected
• Risk: MEDIUM
• Verified source baseline: dev @ cd16ae2830ad656113e0303f0123b2ffb39084f4
• Current release topology: dev -> main
• Source branch: NONE EXPECTED
• PR: NONE EXPECTED
• Exact authorized implementation base: NONE
• Owner / verification agent: not yet assigned
• Independent reviewer: different agent instance from any future source implementer; verification evidence is reviewed at its exact source/deployment identities
• Runtime/provider effect at this gate: NONE

Live baseline rebind - 2026-08-27

The first control-pre-review candidate was based on dev @ b08e309103a7a5a9289038293f92549c8a4388cb. During final verification, dev advanced by four commits to cd16ae2830ad656113e0303f0123b2ffb39084f4.

Fresh comparison showed only theme/test-snapshot changes; none of the APP-04 Publisher Services seams changed. The following exact files were re-read at cd16ae2830ad656113e0303f0123b2ffb39084f4 and retain the generic behavior specified below:

• src/entities/publisher/ui/PublisherServiceConfiguration/PublisherServiceConfiguration.tsx
• src/widgets/PublisherAdministration/usePublisherAdministrationEditor.ts
• src/entities/publisher/api/hooks/useDistributionPlatformOptions.ts

This issue is therefore rebound to the new exact live dev baseline rather than relying on the stale snapshot. Any later dev movement before integration verification requires the same fresh re-read.

The CTO product decision is:

• JISC_NBK remains a known inactive/non-assignable option and may be shown disabled;
• FIGSHARE and CAMBRIDGE_UNIVERSITY_LIBRARY are retired services and must not appear as assignment choices after controlled backend/data cutover.

thoth-app must not encode those names as a local denylist. Backend-owned option membership remains authoritative.

2. Objective

Verify that the existing generic Publisher Services UI correctly reflects the backend retirement of Figshare/Cambridge without adding frontend platform policy, while preserving JISC as a visible disabled option and preserving existing optimistic-concurrency, server-normalization and distribution-job-creation-disabled behavior.

3. Live-source finding: no app code change is currently required

At dev @ cd16ae2830ad656113e0303f0123b2ffb39084f4, both service-configuration editors implement the required generic contract.

3.1 Active-publisher editor

src/entities/publisher/ui/PublisherServiceConfiguration/PublisherServiceConfiguration.tsx builds editor rows from:

1. backend distributionPlatformOptions; plus
2. any currently enabled platform missing from that option list, synthesized as non-assignable so an edit cannot silently drop existing server state.

Therefore:

• an unselected platform omitted by the backend is absent from the editor;
• a backend-returned JISC_NBK with assignable=false remains visible disabled;
• an omitted-but-still-enabled retired value remains visible/removable until backend data reconciliation removes it;
• no platform-specific client policy is required.

3.2 Staff publisher editor

src/widgets/PublisherAdministration/usePublisherAdministrationEditor.ts implements the same rule: backend options plus any currently enabled value missing from the option list, with absent metadata treated as non-assignable.

3.3 Option loading

src/entities/publisher/api/hooks/useDistributionPlatformOptions.ts simply fetches/caches the backend option list under one stable key. It performs no local platform filtering.

3.4 Existing tests

Existing focused tests at the prior baseline already characterized the generic non-assignable behavior, including a backend-returned non-assignable JISC option disabled when unselected and an already-enabled non-assignable platform removable but not re-addable. The four intervening commits do not touch those test files or the relevant source seams.

At the future verification gate, re-run the exact current focused tests against the then-current app source rather than treating prior results as current evidence.

Because Figshare/Cambridge disappearance follows from backend option omission plus prior assignment reconciliation, adding a frontend source/test rule explicitly naming those platforms would risk introducing the local eligibility matrix this programme prohibits.

4. Required upstream contract

thoth-pub/thoth#840 (BE-05) owns the authoritative backend change. Its revised candidate requires:

• all 17 stable DistributionPlatform enum identities remain;
• Figshare/Cambridge become inactive + non-assignable and are omitted from distributionPlatformOptions;
• JISC NBK remains in distributionPlatformOptions with assignable=false;
• distributionPlatformOptions therefore becomes a 15-row visible assignment-option projection;
• executable GraphQL field/type/enum/nullability shape remains unchanged;
• the GraphQL description of distributionPlatformOptions changes so the server no longer falsely calls the 15-row projection the full platform inventory.

The description-only SDL change is expected and compatible. APP-04 must not require byte-identical SDL and must not re-pin graphql/schema.v1.7.0.graphql or regenerate gql/ solely because a server-side description changed and the returned list became a subset. The app's consumed executable types remain compatible because the enum still contains all 17 values and the option object shape is unchanged.

APP-04 verifies the actual merged/deployed BE-05 contract; it does not guess a candidate or moving schema.

5. Critical rollout dependency: enabled retired assignments

The current generic app intentionally displays a backend-omitted platform if it is still enabled in a publisher's protected service configuration. This is correct compatibility behavior: hiding an enabled server value would conceal state that a complete-set replacement must account for.

The product requirement that Figshare/Cambridge be completely absent from assignment choices is therefore satisfied by rollout ordering, not frontend special-casing:

1. BE-05 source is independently reviewed/merged but not yet backend-activated;
2. DIS-03 consumes that exact contract, merges and is separately promoted so its executable/scheduled retirement is runtime-effective;
3. production/test backend state is separately audited;
4. every current CUL/Figshare assignment/job is dispositioned and, where required, disabled through the canonical backend coordinator;
5. reconciliation proves no unexplained enabled retired assignment remains;
6. BE-05 backend behavior is deployed/activated;
7. APP-04 verifies the app against that exact state.

If this state cannot be established, APP-04 is HOLD. Do not add a frontend hide-by-name rule to mask unresolved backend configuration.

6. Explicit scope

APP-04 is currently a zero-source-change integration verification task.

It must verify:

• backend distributionPlatformOptions contains neither FIGSHARE nor CAMBRIDGE_UNIVERSITY_LIBRARY;
• backend still returns JISC_NBK with assignable=false;
• verified publisher configurations do not retain enabled retired values after reconciliation;
• active-publisher editor offers neither retired platform;
• staff publisher editor offers neither retired platform;
• JISC NBK remains visible and disabled/non-selectable when unselected;
• ordinary assignable destinations still render according to backend metadata;
• no local package/platform/retirement matrix or denylist exists;
• stale-write, server-normalized-state and DISTRIBUTION_JOB_CREATION_DISABLED semantics remain unchanged;
• the app remains compatible with BE-05's description-only SDL drift without changing pinned local SDL/generated client artifacts.

7. Non-goals

APP-04 must not:

• implement or duplicate backend platform visibility/eligibility policy;
• hard-code FIGSHARE or CAMBRIDGE_UNIVERSITY_LIBRARY as hidden client values;
• silently suppress an enabled backend value;
• alter packages, linkage, durable-job semantics, auth or API behavior;
• perform upstream assignment/job reconciliation;
• edit the pinned v1.7 SDL or generated gql/ merely for BE-05's description-only change;
• create a branch/PR without first demonstrating an actual app defect and amending this specification;
• deploy/release/merge or access runtime/browser/provider systems without separate authorization.

8. Cross-repository impact

Contract	Impact
backend stable enum	CONSUMED / COMPATIBLE - remains 17 values
backend option response membership	CONSUMED / AFFECTED - 17 -> 15 visible options
backend executable GraphQL shape	COMPATIBLE - no field/type/enum/nullability change
backend SDL descriptions	COMPATIBLE DESCRIPTION-ONLY DRIFT
app pinned schema/generated types	NO CHANGE REQUIRED for this retirement alone
app presentation	VERIFICATION REQUIRED
app authorization	NOT AFFECTED
upstream data reconciliation	OUT OF SCOPE; owned by backend rollout controls
dissemination execution	OUT OF SCOPE; owned by DIS-03

Upstream owners:

• BE-05: thoth-pub/thoth#840
• DIS-03: thoth-pub/thoth-dissemination#101

APP-04 must use exact merged/deployed upstream identities when verification occurs.

9. Invariants

1. Backend option membership remains the single source of option visibility.
2. Enabled server values missing from option metadata are never silently dropped/hidden by the app.
3. JISC remains generically visible-disabled because the backend returns it as non-assignable.
4. Retired unselected values disappear because the backend omits them, not because the app recognizes their names.
5. No GraphQL generated artifact is rewritten for a description-only upstream SDL change.
6. Existing concurrency/error truthfulness remains intact.

10. Source write budget

Existing files permitted: NONE

New files: NONE

Deletion/move/rename: NONE

Branch / PR: NONE EXPECTED

If integration evidence proves a real app defect, return:

HOLD - APP-04 SOURCE AMENDMENT REQUIRED

Before any code edit, amend this issue with:

• exact demonstrated defect/evidence;
• exact live dev base and overlap state;
• bounded source/test write paths;
• changed cross-repository assumptions if any;
• acceptance/tests;
• automatic CI side effects;
• separate exact-base implementation authorization.

Any source fix must remain generic/backend-driven and must not hard-code retired platform eligibility/visibility.

11. Verification evidence

11.1 Source-level verification

Against the exact app source used for integration, confirm the generic editor seams above remain unchanged or semantically equivalent. Re-read them if dev has moved; do not rely on this baseline by memory.

Run the exact focused service-configuration/editor tests against that source and record their results. No test/source mutation is authorized merely to add retired-platform names.

11.2 Backend/API verification

Under a separately authorized suitable test/non-production deployment or controlled production cutover, capture bounded evidence of:

• exact backend source/deployment identity;
• exact app source/deployment identity;
• distributionPlatformOptions membership/assignability facts;
• relevant representative publisher configuration state;
• no enabled retired assignment in the verified population after reconciliation.

Do not expose tokens, credentials or unbounded protected payloads.

11.3 UI verification

Under separately authorized browser/runtime read access, verify:

• active-publisher editor: no Figshare/Cambridge choice;
• staff publisher editor: no Figshare/Cambridge choice;
• JISC visible disabled/non-selectable when unselected;
• ordinary options remain rendered from backend metadata;
• existing failed-save/job-creation-disabled truthfulness remains unchanged.

Browser/runtime access is a separate permission; it is not authorized by this specification candidate itself.

12. Candidate verification action-authorization matrix

This matrix is specification content only; it is not active authorization. Exact integration verification requires a later authorization bound to concrete backend/app deployment identities.

Action	Candidate authorization
repository/GitHub read inspection	YES
source/worktree edit	NO
create/delete/move/rename files	NO
branch creation	NO
commit/push	NO
PR creation/update	NO
issue/comment mutation for evidence	YES
local read-only source/test verification	YES, if it writes no repo artifacts
provider/runtime/API read	SEPARATE LATER AUTHORIZATION REQUIRED
browser verification	SEPARATE LATER AUTHORIZATION REQUIRED
provider/runtime write	NO
upstream data mutation	NO
manual CI dispatch/rerun	NO
release/merge/deployment/activation	NO

13. Automatic side effects

Because APP-04 currently has no source branch/PR, it has no expected code-delivery side effect.

If future evidence requires app source work, this specification must be amended and live CI side effects re-verified before source/PR authorization. Do not inherit assumptions from this zero-change plan.

14. Existing app release interaction

APP-RR-01 / #142 remains the existing repository dev -> main release-readiness control, but its recorded source snapshot predates current dev @ cd16ae2830ad656113e0303f0123b2ffb39084f4. Any future promotion must reconstruct #142 against the then-exact dev/main pair.

Because APP-04 currently has no source diff, it does not itself alter a release candidate. If APP-04 later requires source work and merges to dev, the release-readiness control must again be freshly reconstructed against the new exact candidate before promotion.

15. Acceptance criteria

• exact merged/deployed BE-05 identity is recorded;
• exact DIS-03 runtime-retirement identity/state is recorded;
• assignment/job reconciliation evidence establishes no unexplained enabled CUL/Figshare assignment in the verified scope;
• backend option response omits both retired platforms and retains JISC assignable=false;
• active-publisher editor exposes neither retired platform;
• staff publisher editor exposes neither retired platform;
• JISC remains visible disabled/non-selectable when unselected;
• other backend-provided options render normally;
• no frontend retirement/eligibility denylist or matrix exists;
• existing configuration error/concurrency semantics remain unchanged;
• no pinned SDL/generated-client change was made solely for the backend description drift;
• no app source branch/PR was created unless prior defect evidence caused an approved specification amendment.

16. Rollout / rollback

APP-04 itself has no rollout because it contains no source change. It observes the controlled upstream rollout after BE-05/DIS-03/data gates are complete.

If verification fails, HOLD upstream activation/closure and classify the failure:

• unresolved backend assignment/state -> backend reconciliation issue;
• incorrect backend option contract -> BE-05 issue;
• actual generic app defect -> amend APP-04 before code work.

Do not roll back or mask upstream state from the frontend merely to make the UI appear clean.

17. HOLD / STOP

HOLD if:

• this exact rebound verification specification is not independently reviewed and CTO-approved;
• BE-05 is unmerged/unpinned or not deployed in the verification environment;
• DIS-03 runtime retirement is incomplete;
• enabled retired assignments/jobs remain unresolved;
• backend executable schema shape changes beyond the approved description-only drift without an explicit compatibility decision;
• current app source no longer implements the generic option behavior described above;
• verification requires runtime/browser access not separately authorized;
• a proposed fix requires hard-coded platform policy.

STOP if APP-04 begins:

• introducing a Figshare/Cambridge frontend denylist;
• silently dropping enabled server values;
• changing package/linkage/job/domain semantics;
• performing upstream data reconciliation;
• editing generated/pinned GraphQL artifacts without a demonstrated executable contract need;
• changing auth/provider/runtime policy;
• releasing/deploying/merging without separate authorization.

18. Current authorization

Authorized now:

• read-only repository/GitHub inspection;
• issue/specification and bounded release/programme ledger coordination mutation.

Not authorized now:

• source/file changes;
• branch creation/update;
• commit/push;
• PR creation/mutation;
• manual CI dispatch/rerun;
• API/provider/runtime/browser access;
• upstream data mutation;
• deployment/release/merge/production activation.

19. Next action

Obtain independent review and CTO approval of this revised, rebound zero-source-change verification specification. Then leave APP-04 HOLD until BE-05, DIS-03 and assignment-reconciliation gates supply exact deployment/state identities for a separately authorized integration verification.

[ja573]

CONTROL PRE-REVIEW - REVISED VERIFICATION SPECIFICATION READY FOR INDEPENDENT REVIEW

Decision type: CONTROL PRE-REVIEW ONLY - NOT INDEPENDENT APPROVAL.

I re-reviewed APP-04 against live app doctrine/source at:

• issue body updatedAt: 2026-08-27T14:02:09Z
• dev: b08e309103a7a5a9289038293f92549c8a4388cb

Findings resolved/confirmed

1. Zero-source-change conclusion - CONFIRMED. Both the active-publisher editor and staff editor derive rows from backend distributionPlatformOptions plus any currently enabled value missing from the option list. The option hook itself performs no local platform filtering. Once backend state is reconciled and BE-05 omits CUL/Figshare, the two retired choices disappear generically; JISC remains visible-disabled because the backend still returns it as non-assignable.
2. Enabled-retired-state invariant - CONFIRMED. If an omitted platform remains enabled, the app deliberately continues to show it as removable. Complete hiding therefore depends on upstream assignment reconciliation; a frontend denylist would conceal unresolved canonical state and is prohibited.
3. SDL compatibility wording - CORRECTED. Revised BE-05 now changes the distributionPlatformOptions description only, while preserving enum/field/type/nullability shape. APP-04 no longer requires byte-identical SDL and explicitly prohibits re-pinning the local v1.7 SDL or regenerating gql/ solely for that description-only drift and smaller response list.
4. Write budget - CONFIRMED. APP-04 remains zero-source-change: no files, branch or PR are authorized/expected. A demonstrated app defect must first cause a specification amendment and fresh exact-base authorization.
5. Release interaction - CONFIRMED. With no source diff, APP-04 does not itself alter the current app release candidate. Any future source amendment must reconstruct release/CI state afresh.

Gate

No additional blocking specification finding is known from this control pre-review. This is not an independent review decision because the same control agent prepared/amended the candidate.

Current gate: HOLD - distinct independent specification review -> CTO specification approval -> later separately authorized integration verification after BE-05/DIS-03/data gates.

No source, browser/runtime/API access, data mutation, branch/PR, CI dispatch, release, deployment or activation is authorized by this comment.

[ja573]

CONTROL PRE-REVIEW BASELINE REBIND - SUPERSEDES PRIOR BASELINE IDENTITY

Decision type: CONTROL PRE-REVIEW ONLY - NOT INDEPENDENT APPROVAL.

During the final verification pass after comment 5440272831, live dev moved from the candidate baseline b08e309103a7a5a9289038293f92549c8a4388cb to:

cd16ae2830ad656113e0303f0123b2ffb39084f4

Fresh comparison reports four intervening commits. Their changed paths are confined to shared theme source/tests and unrelated snapshot files; none touches the APP-04 Publisher Services seams.

I then re-read at exact cd16ae2830ad656113e0303f0123b2ffb39084f4:

• src/entities/publisher/ui/PublisherServiceConfiguration/PublisherServiceConfiguration.tsx
• src/widgets/PublisherAdministration/usePublisherAdministrationEditor.ts
• src/entities/publisher/api/hooks/useDistributionPlatformOptions.ts

The generic backend-driven behavior remains as specified: backend options plus still-enabled missing values, no local platform filter, and no frontend retirement matrix.

The APP-04 issue body has therefore been rebound to the exact new baseline; current candidate-body write timestamp is 2026-08-27T14:06:14Z.

This comment supersedes only the stale baseline identity in pre-review comment 5440272831. Its substantive findings remain consistent with the freshly read source. It still does not constitute independent approval.

Current gate remains HOLD - distinct independent specification review -> CTO specification approval -> later separately authorized integration verification.

No app source, branch, PR, test mutation, browser/runtime/API access, deployment, release or production action is authorized.

[ja573]

INDEPENDENT SPECIFICATION REVIEW HANDOFF - APP-04

Review requested. This handoff is not a review decision and authorizes no app/runtime action.

Review the complete current APP-04 verification specification in this issue, headed:

INTEGRATION-VERIFICATION SPECIFICATION CANDIDATE - REVISED AFTER CONTROL PRE-REVIEW AND LIVE BASELINE REBIND - AWAITING INDEPENDENT REVIEW AND CTO APPROVAL

Fresh baseline verified immediately before this handoff:

• repository: thoth-pub/thoth-app
• dev: cd16ae2830ad656113e0303f0123b2ffb39084f4
• candidate issue body was re-fetched before this comment; if materially edited after this handoff, return HOLD and review the new body
• prior control evidence: comments 5440272831 and 5440314423; both explicitly not independent approval, with the latter rebinding the baseline after dev moved
• risk: MEDIUM

Required independent inspection

Inspect the exact app source rather than trusting the zero-change conclusion. Re-read at the exact reviewed dev SHA:

• src/entities/publisher/ui/PublisherServiceConfiguration/PublisherServiceConfiguration.tsx
• src/widgets/PublisherAdministration/usePublisherAdministrationEditor.ts
• src/entities/publisher/api/hooks/useDistributionPlatformOptions.ts
• focused existing service-configuration/editor tests needed to establish the generic behavior

Verify at minimum:

1. both editors derive rows generically from backend distributionPlatformOptions plus currently enabled values missing from that list;
2. an omitted, unselected retired value therefore disappears without any client-side platform denylist;
3. an omitted-but-still-enabled value deliberately remains visible/removable and non-reselectable, so complete retirement presentation correctly depends on backend assignment reconciliation rather than frontend masking;
4. backend-returned JISC_NBK with assignable=false remains generically visible disabled/non-selectable when unselected;
5. the option hook adds no local filtering or eligibility policy;
6. BE-05's intended response-membership change and description-only SDL drift remain executable-schema compatible with the app's pinned v1.7 types, so no SDL re-pin or gql/ regeneration is justified solely by this retirement;
7. optimistic concurrency, server-normalized state and DISTRIBUTION_JOB_CREATION_DISABLED truthfulness are not affected by the proposed upstream change;
8. the zero-source-change write budget is correct: no branch, file edit, generated artifact or PR should be created unless future integration evidence proves an actual generic app defect;
9. rollout ordering correctly requires BE-05/DIS-03 runtime retirement plus controlled assignment/job reconciliation before UI integration verification;
10. future browser/API/runtime verification remains separately authorized and bound to exact deployed backend/app identities.

Required decision record

Post a new comment here using exactly one decision:

• APPROVED - the zero-source-change verification specification is correct as written;
• CHANGES REQUIRED - list each blocking correction/evidence gap with exact source/spec references;
• BLOCKED - identify the authority/dependency/environment condition preventing safe specification approval.

Record the reviewer context/model, exact dev SHA reviewed, and whether the issue body still matched this handoff's candidate when review began.

APPROVED would approve only the verification specification. It would not authorize source changes, browser/API/runtime access, data reconciliation, branch/PR activity, release, deployment or production activation. CTO specification approval and the later exact-environment integration-verification authorization remain separate gates.

[ja573]

CONTROL REBIND / FRESH INDEPENDENT-SPECIFICATION HANDOFF — APP-04

Decision type: CONTROL-PLANE REBIND ONLY — NOT INDEPENDENT APPROVAL.

The prior APP-04 candidate and independent-review handoff were bound to stale app source dev @ cd16ae2830ad656113e0303f0123b2ffb39084f4. Live dev is now:

• dev @ 4cfe54ca9b4287e36f7f726b5135397ba9f40ebc
• tree 858c386ea6e5bdde109c67147ed23db57d8f22e1

main @ 92764c33ad5164cebbb43a94c4be77d7a9e5e1d7 carries that same source tree after the reviewed production promotion.

Baseline movement assessment

Comparison from the prior APP-04 baseline cd16ae2830ad656113e0303f0123b2ffb39084f4 to current dev shows the later APP-IMPORT-ORCID-NORMALIZE-01 / PR #159 delta. That work is confined to bulk-import ORCID validation/parser tests and does not touch the APP-04 Publisher Services seams.

I freshly re-read at exact 4cfe54ca9b4287e36f7f726b5135397ba9f40ebc:

• src/entities/publisher/ui/PublisherServiceConfiguration/PublisherServiceConfiguration.tsx
• src/widgets/PublisherAdministration/usePublisherAdministrationEditor.ts
• src/entities/publisher/api/hooks/useDistributionPlatformOptions.ts

The candidate's zero-source-change premise remains intact:

1. the active-publisher editor builds rows from backend distributionPlatformOptions plus any currently enabled value omitted from that list, synthesizing omitted enabled values as non-assignable;
2. the staff editor implements the same backend-options-plus-enabled-missing-values rule;
3. the option hook only fetches/caches the backend list and adds no local platform filtering or eligibility policy;
4. therefore an omitted, unselected Figshare/Cambridge option disappears generically, an omitted-but-still-enabled retired value remains visible/removable until data reconciliation, and a backend-returned JISC option with assignable=false remains generically visible-disabled;
5. no frontend Figshare/Cambridge denylist is justified by current source.

No APP-04 source amendment is indicated by this rebind.

Upstream authority remains unchanged

Fresh live programme state still has:

• BE-05 / thoth-pub/thoth#840: revised specification candidate; implementation not authorized/merged;
• DIS-03 / thoth-pub/thoth-dissemination#101: revised specification candidate; implementation not authorized and explicitly dependent on the future exact merged BE-05 contract.

Accordingly APP-04 cannot perform its final integration verification yet.

Superseded review identity

The earlier independent-review handoff comment 5441162673 is superseded only as to the exact app baseline identity. It did not receive a recorded independent decision before dev moved, so no approval is carried forward by inference.

Fresh independent review handoff

A distinct reviewer should now review the existing APP-04 zero-source-change verification specification against exact app source:

dev @ 4cfe54ca9b4287e36f7f726b5135397ba9f40ebc

and record exactly one decision: APPROVED, CHANGES REQUIRED, or BLOCKED.

The review should re-confirm the three source seams above, the backend-owned visibility contract, enabled-retired-value preservation, JISC visible-disabled behavior, compatibility with BE-05's intended response-subset/description-only SDL drift, and the correctness of a zero app source write budget.

An APPROVED decision would approve the verification specification only. It would not authorize browser/API/runtime access, data reconciliation, source changes, branch/PR activity, deployment or production mutation.

After independent specification approval, CTO specification approval remains a separate gate. Only then should APP-04 sit on dependency HOLD pending exact merged/deployed BE-05, DIS-03 runtime retirement and controlled assignment/job reconciliation, followed by separately authorized integration verification.

Current gate: HOLD — FRESH INDEPENDENT SPECIFICATION REVIEW AT 4cfe54ca... -> CTO SPECIFICATION APPROVAL -> UPSTREAM BE-05/DIS-03/DATA DEPENDENCY HOLD.