APP-01: Publisher service configuration UI

[ja573]

Status

PROPOSED - AWAITING CTO SPECIFICATION APPROVAL

Implementation: NOT AUTHORIZED

Current gate: HOLD

Programme

Publisher Services and Distribution Configuration

Programme stage: Phase C - application interfaces

Parent programme issue: thoth-pub/thoth#765

Repository responsibility

Repository: thoth-pub/thoth-app

thoth-app owns authenticated publisher/staff UI and client behaviour only.

thoth-pub/thoth owns:

• publisher package semantics;
• package capabilities;
• distribution-platform inventory and descriptors;
• linked-platform normalization;
• service-configuration authorization;
• configuration version/concurrency semantics;
• durable distribution-job lifecycle and state;
• the GraphQL schema.

APP-01 must consume those contracts and must not reproduce them as independent frontend policy.

Task identity

Task ID: APP-01

Risk: MEDIUM

Coordination issue: this issue.

Implementation decomposition is proposed before coding:

• APP-01A - v1.7 contract pin and publisher read-only configuration;
• APP-01B - superuser configuration editing and concurrency/error UX;
• APP-01C - truthful latest back-catalogue job presentation.

Each child is an independently implementable repository-local task and therefore requires its own approved issue/specification, exact authorized base SHA, branch and PR.

No implementation branch or PR is authorized by this issue alone.

Current repository baseline

Observed development branch:

dev @ 7a4e7c6ceaec36fbdb201eaeb9ae36985a709889

Observed release/default branch:

main @ 3f2c4a3428641078b820f78c8e08a844b49c71de

Both currently resolve to source tree:

2ea8c49a1936dd25cbea74a749532a32bb6d8399

Observed topology:

dev -> main

Normal task target under the merged root AGENTS.md:

dev

Authorized implementation base SHA:

NONE - implementation is not yet authorized.

Every child implementation must perform a fresh preflight and record the exact dev SHA separately when implementation is explicitly authorized.

Branch-readiness gate

BR-APP-01 remains separate branch-normalization work.

APP-01 requires either:

1. completed BR-APP-01; or
2. an explicit durable CTO exception permitting APP-01 child tasks to use the current dev -> feature/... -> dev topology.

The proposed exception does not authorize branch normalization, main promotion, Vercel/provider changes, deployment or production activation.

Upstream contract

Upstream repository: thoth-pub/thoth

Upstream release: v1.7.0

Exact release/source commit:

40e9c06d4ab76217c3ef277dd539d3b5580e2bb8

Exact source tree:

8797558959fcf1f418eb33ca080b469e97783cbd

Backend contracts consumed:

• BE-01 - Publisher package model, implementation PR BE-01: add inactive publisher package model thoth#779;
• BE-02 - Distribution platform model, implementation PR feat(publisher-services): implement BE-02 distribution platforms thoth#805;
• BE-03 - Protected service configuration, implementation PR feat(publisher-services): implement BE-03 protected service configuration thoth#809;
• BE-04 - Durable distribution jobs, corrected specification PR docs(publisher-services): reconcile BE-04 implementation blockers thoth#817 and implementation/reconciliation PR BE-04: implement durable distribution jobs thoth#816.

APP-01 must pin the v1.7.0 contract as a whole rather than regenerate against an unpinned moving API.

Exact SDL control

The upstream repository does not commit the generated thoth-client/assets/schema.graphql artifact. The canonical upstream schema generation path is create_schema().as_sdl().

Before APP-01A implementation proceeds:

1. generate the GraphQL SDL using the canonical upstream generation path from exactly 40e9c06d4ab76217c3ef277dd539d3b5580e2bb8;
2. record the generated SDL SHA-256 in this issue or APP-01A's issue;
3. store/use an immutable local contract snapshot as APP-01 codegen input;
4. record its provenance: upstream repo, v1.7.0, commit and tree;
5. regenerate gql/;
6. record the complete generated-code diff;
7. prove regeneration from the same pinned SDL is clean/deterministic.

Code generation against https://api.test.thoth.pub/graphql is not acceptable evidence of exact v1.7.0 compatibility for APP-01.

If the upstream GraphQL schema changes while APP-01 is in progress, STOP. Do not silently regenerate against the new schema. Perform an explicit compatibility assessment and re-pin only under an approved scope/contract update.

Dependencies

Satisfied upstream source dependencies:

• BE-01: satisfied by v1.7.0;
• BE-02: satisfied by v1.7.0;
• BE-03: satisfied by v1.7.0;
• BE-04: satisfied by v1.7.0 for the job-aware read contract.

Remaining app/readiness dependencies:

• explicit BR-APP-01 completion or CTO branch exception;
• app portion of CG-11 resolved, or an explicit CTO readiness exception;
• exact v1.7.0 SDL generated and digest recorded;
• this APP-01 specification approved;
• child issue/specification approved before each child implementation.

MIG-01

MIG-01 is not a source-code or GraphQL-contract dependency for APP-01 implementation.

It does affect production data population. Until production package/platform backfill is reconciled, APP-01 must render the API's actual current state rather than invent expected legacy configuration.

Production-facing release/activation must separately decide whether MIG-01 completion is required before publisher users should rely on the displayed configuration.

APP-01 must not perform, invoke or simulate MIG-01.

Problem

The v1.7.0 backend now owns authoritative publisher service configuration, including package, effective package capabilities, enabled distribution platforms, linked-platform normalization, optimistic concurrency, and durable distribution-job reporting.

thoth-app currently has no UI consuming this contract.

Publisher users need to see their permitted service configuration. Superusers need a bounded editing interface using the backend's dedicated mutation. Job-aware presentation must show actual BE-04 durable job state and must not derive delivery status from desired configuration.

Scope

Publisher-facing service configuration

For the active authenticated publisher, display:

• current subscription package;
• effective package capabilities returned by the API;
• currently enabled distribution platforms;
• platform display labels and applicable backend-provided metadata;
• read-only service configuration for ordinary publisher users.

Capabilities must be consumed from effectiveCapabilities. Do not implement a package-to-capability matrix in TypeScript.

Platform interaction/display must consume distributionPlatformOptions, including backend-owned linked-group and assignability metadata. Do not maintain an OAPEN/DOAB rule table in the frontend.

Superuser configuration editing

For superusers only, provide controls to replace:

• subscription package;
• enabled distribution platforms.

Mutation: replacePublisherServiceConfiguration.

The mutation request must include the updatedAt value from the exact configuration version the user edited as expectedUpdatedAt.

Package changes must never implicitly add/remove distribution platforms in client code.

Linked platform closure must not be implemented as a second authoritative frontend algorithm. The UI may present the backend linkage clearly, but the submitted state and returned server-normalized state remain authoritative.

After a successful mutation:

• discard any locally assumed final state;
• use the exact mutation response and/or a fresh protected configuration read;
• update/invalidate query state from the server result;
• show success only after the server has accepted the mutation.

Optimistic-concurrency behaviour

The backend GraphQL error classification STALE_SERVICE_CONFIGURATION must be preserved by app GraphQL error plumbing.

On a stale write:

• do not claim success;
• do not automatically overwrite the newer configuration;
• re-read the current configuration;
• clearly tell the user that the configuration changed since they loaded it;
• require a deliberate new edit/retry against the fresh version.

Do not parse human-readable error strings to identify concurrency errors.

Job-creation-disabled behaviour

Automatic distribution-job creation is intended to remain OFF.

The app must not attempt to activate or configure that switch.

When the API rejects a qualifying new automatic-push activation with DISTRIBUTION_JOB_CREATION_DISABLED:

• treat the mutation as failed;
• make clear that the configuration was not saved;
• leave/refetch client state from the API;
• do not show a pending/synthetic onboarding job;
• do not retry automatically.

Job-aware presentation

Where superuser UI displays onboarding/job state, use the actual BE-04 contract.

Use the nullable latestBackCatalogueJob associated with the server's service-configuration report surface.

If no job exists, represent that truthfully, for example:

No back-catalogue onboarding job is recorded.

A null job must never be transformed into:

• success;
• failure;
• pending;
• not required;
• already disseminated;
• not disseminated.

When a job exists, display only API-backed facts useful for staff, such as:

• job status;
• targets;
• attempt count;
• latest bounded worker-reported failure information where present;
• relevant timestamps where useful.

Do not infer dissemination execution or observed remote delivery from a durable job alone.

Maintain these distinctions:

desired configuration != durable distribution job != dissemination execution/observed delivery

Existing app integration

Prefer extending the existing authenticated publisher profile path rather than creating a parallel publisher administration architecture.

Reuse:

• /admin/publisher;
• the existing Profile widget;
• active publisher state from the publisher state machine;
• src/entities/publisher Feature-Sliced Design boundaries;
• generated graphql(...) documents;
• GraphqlService;
• TanStack Query hooks;
• existing user/superuser data for UI affordances.

Do not change NextAuth/Zitadel policy.

App GraphQL error plumbing

Current GraphqlService keeps the first GraphQL error message but discards error extensions.

APP-01B may make a narrowly scoped, backwards-compatible enhancement that preserves the stable GraphQL error type for caller inspection while retaining the existing useful message behaviour.

This change must:

• not log bearer tokens or request headers;
• not expose full sensitive GraphQL payloads;
• keep existing callers compatible;
• have focused unit tests;
• avoid introducing backend-specific policy into the shared transport layer beyond preserving server-returned structured error metadata.

Authorization and security invariants

• The Thoth backend remains the authorization authority.
• Hidden controls are presentation only, never an authorization boundary.
• Ordinary publisher users must not receive a superuser mutation path from UI presentation.
• Direct/manual requests remain the backend's responsibility to deny.
• No service/machine credential may be placed in browser code.
• No NextAuth/Zitadel policy or role semantics change is in scope.
• Do not create a frontend role/authorization matrix mirroring backend policy.
• Do not log access tokens, credentials, authorization headers or complete sensitive GraphQL request/response payloads.
• Authorization failures must not leave stale optimistic UI that appears saved.

UI/domain invariants

• No package capability matrix exists in the frontend.
• No independent linked-platform normalization algorithm exists in the frontend.
• No platform eligibility matrix exists in the frontend.
• No distribution-job state machine exists in the frontend.
• No configuration-version semantics are reimplemented in the frontend.
• Server-normalized state wins after every mutation.
• No job is never treated as evidence of dissemination success or failure.
• Package selection never implicitly changes platform assignments in client logic.
• Non-assignable options follow API-provided metadata.
• Existing publisher/staff workflows must not regress.

Proposed implementation decomposition

APP-01A - Contract pin and publisher read-only configuration

Scope:

• capture/pin exact v1.7.0 SDL;
• make codegen deterministic against that pinned artifact;
• regenerate gql/;
• add publisherServiceConfiguration query;
• add distributionPlatformOptions query;
• add entity/service/hooks for reads;
• render current package, effective capabilities and enabled platforms in the existing publisher profile;
• ordinary publisher presentation remains read-only.

No mutation.
No job-status presentation.
No shared GraphQL error plumbing change unless required only to preserve existing behaviour.

APP-01B - Superuser service-configuration editing

Depends on APP-01A.

Scope:

• superuser-only edit controls;
• replacePublisherServiceConfiguration;
• expectedUpdatedAt;
• server-normalized mutation result;
• stale-write UX;
• job-creation-disabled UX;
• narrowly scoped structured GraphQL error preservation;
• query invalidation/refetch after outcomes.

No backend change.
No job worker.
No job creation.
No provider/runtime configuration.

APP-01C - Truthful back-catalogue job presentation

Depends on APP-01A; may follow APP-01B unless review shows no file overlap.

Scope:

• superuser-only consumption of the existing service-configuration report surface for the active publisher;
• nullable latestBackCatalogueJob;
• status, targets, attempt/failure data that exists in the API;
• explicit no-job semantics.

No APP-02 report page.
No CSV report/export.
No broad staff filters.
No dissemination execution UI.
No observed-delivery model.

Explicit non-goals

• APP-02 staff subscription/reporting UI;
• APP-03 licence options;
• MIG-01 audit/backfill;
• DIS-01 comparison/cutover;
• DIS-02 worker;
• OAI-PMH;
• changing package/capability semantics;
• changing distribution platform inventory;
• changing linked-platform normalization;
• changing backend authorization;
• changing durable-job lifecycle;
• creating jobs locally;
• activating automatic job creation;
• running migrations;
• provider/Vercel reads or writes;
• deployment;
• production release or activation;
• branch normalization;
• general refactoring of publisher administration.

If implementation starts absorbing any of these, STOP for scope review.

Expected test coverage

APP-01A

• an authorized publisher can render its permitted configuration;
• package comes from protected API configuration;
• capabilities come from effectiveCapabilities;
• no frontend package-capability lookup exists;
• enabled platforms come from API assignments;
• display/link/assignability metadata comes from distributionPlatformOptions;
• ordinary publisher UI exposes no editing controls;
• changing active publisher reloads the applicable protected configuration;
• authorization/API failure does not fabricate configuration;
• generated GraphQL types correspond to the exact pinned v1.7.0 SDL;
• rerunning generation from the pinned SDL produces no unexplained generated diff.

APP-01B

• mutation sends the exact configuration token as expectedUpdatedAt;
• successful mutation replaces client state with the server-normalized result;
• package editing does not implicitly alter platform state in client code;
• backend-linked normalization is reflected from the response;
• ordinary publisher UI exposes no mutation controls;
• backend remains authoritative if a mutation is attempted outside UI controls;
• STALE_SERVICE_CONFIGURATION produces explicit stale-write UX and a refresh, with no success state;
• stale writes are never blindly retried;
• DISTRIBUTION_JOB_CREATION_DISABLED is shown as a failed/non-saved change;
• authorization/API failures leave client state consistent with the server;
• structured GraphQL error metadata is preserved without regressing existing GraphQL callers.

APP-01C

• a real latest job is rendered from BE-04 state;
• job status is never derived from configured platforms;
• attempt/failure presentation comes only from API fields;
• null latest job renders as no recorded job;
• null latest job does not render success, failure, pending or dissemination status;
• desired configuration and job state remain visually/textually distinct;
• no APP-02 filters/CSV/reporting behaviour is introduced.

Regression/security

• existing publisher profile functionality remains functional;
• non-superusers retain their existing publisher behaviour;
• no token/header/full sensitive payload appears in errors or logs;
• existing auth/session flow remains unchanged.

Required validation

For every applicable child PR, reverify package scripts and run/report:

npm ci
npm run generate
npm run lint
npm test -- --run --coverage
npm run build

Also run focused tests for the changed modules.

The generated-code check must use the exact pinned v1.7.0 SDL.

Any pre-existing lint/test/build/codegen failure must be measured and explicitly separated from a regression introduced by the child task.

GitHub CI coverage is currently insufficient by itself to constitute this validation.

CI/readiness dependency

The app portion of shared control gap CG-11 remains open.

A separate repository-local CI/readiness task should determine the approved GitHub gates for:

• lint;
• production build;
• codegen consistency.

Do not modify .github/workflows/* opportunistically in APP-01.

If the CTO chooses to allow APP-01 implementation before CG-11 is closed, the exception and compensating validation requirements must be explicit and durable before implementation authorization.

Compatibility

Backend compatibility baseline is exactly v1.7.0.

APP-01 must remain compatible while:

THOTH_DISTRIBUTION_JOB_CREATION = OFF

That means:

• reads remain useful;
• package-only changes remain governed by the API;
• pull/manual behaviour remains governed by the API;
• qualifying new automatic-push activation may be rejected by the backend;
• APP-01 reports that rejection truthfully and does not activate the switch.

No client assumes DIS-01 or DIS-02 is deployed.

If the upstream v1.7.0 contract is changed by later backend development, existing APP-01 work continues against the pinned contract until an explicit compatibility decision authorizes a re-pin.

Merge/deployment ordering

Repository/source dependency:

thoth v1.7.0 -> APP-01A -> APP-01B / APP-01C

The upstream source contract is already released.

MIG-01 may proceed independently because it affects data population rather than the APP-01 client contract.

APP-01 may be implemented and merged to thoth-app/dev while automatic distribution-job creation remains OFF.

Each child requires:

implementation -> independent exact-head review -> merge readiness/authorization -> merge to dev

Merge to dev is not production release authorization.

Later:

dev validation -> release readiness -> dev/main promotion -> production observation

remain separate gates.

Any PR-triggered Vercel preview/status creation must be identified as an expected automatic side effect of an authorized PR action. It does not authorize provider reads/writes.

Rollout

Prefer additive UI changes.

Initial dev/preview validation should cover:

• ordinary publisher read-only view;
• superuser read/edit;
• one server-normalized linked-platform response;
• stale-write behaviour;
• authorization failure;
• job-creation-disabled behaviour with no false saved state;
• no-job presentation;
• representative actual job presentation if suitable non-production/test data exists.

No provider/runtime access is implied.

APP-01 must not change THOTH_DISTRIBUTION_JOB_CREATION.

Production release remains separately authorized.

Rollback

Primary rollback is an app-only revert of each bounded APP-01 child PR.

No backend rollback, database migration rollback, distribution-job deletion or dissemination cleanup should be required by APP-01 itself.

If a release needs to be withdrawn, revert/hide the app UI while retaining the additive v1.7.0 backend contract.

HOLD conditions

HOLD if:

• live dev base cannot be established;
• the branch exception/BR-APP-01 gate is unresolved;
• the APP-01 or child specification is not approved;
• CG-11/readiness has neither closure nor an explicit CTO exception;
• the exact v1.7.0 SDL and digest are not established;
• generated client types do not match the pinned SDL;
• a materially overlapping app PR appears;
• required provider action is not separately authorized.

BLOCKED conditions

BLOCKED if:

• the current backend contract lacks information required to render correct UI state;
• the backend and app authorization models require contradictory behaviour;
• server-normalized platform state cannot be represented without inventing frontend policy;
• correct concurrency handling requires a backend contract change;
• required job state cannot be obtained from BE-04 without fabricating it;
• safe implementation requires an unapproved cross-repository architecture change.

STOP conditions

STOP if:

• APP-01 begins changing package/platform/domain architecture;
• APP-01 begins implementing APP-02 or APP-03;
• APP-01 begins performing MIG-01 work;
• APP-01 begins implementing dissemination/worker behaviour;
• a new reusable cross-programme abstraction is proposed;
• a task attempts to activate distribution-job creation;
• implementation scope expands into auth-policy or provider configuration changes.

Current authorization

Authorized for the current control step:

• read-only repository/GitHub inspection;
• creation of this repository-local APP-01 issue;
• separately authorized chronological linkage/gate comment on parent issue thoth-pub/thoth#765.

Not authorized:

• source/worktree modification;
• new repository files;
• delete/move/rename;
• branch creation;
• commit;
• push;
• PR creation/update;
• other issue/comment mutation;
• manual CI dispatch/rerun;
• provider/runtime read or write;
• migration execution;
• release/tag/publication;
• merge;
• deployment;
• production activation.

Current gate

HOLD - specification candidate created; implementation is not ready or authorized.

Next actions

1. CTO reviews/approves or amends this APP-01 specification and proposed A/B/C decomposition.
2. Separately resolve/record the BR-APP-01 exception or complete branch normalization.
3. Create/resolve the app-local CG-11 CI/readiness task, or explicitly authorize a temporary readiness exception.
4. Capture the exact v1.7.0 SDL digest under separately authorized work.
5. Prepare APP-01A with a fresh exact dev base.
6. Only after its own approved child specification and explicit action authorization may APP-01A implementation begin.

[ja573]

Specification approval - APP-01

CTO specification decision: APPROVED for the APP-01 coordination/specification recorded in this issue.

Approved scope and controls:

• Programme: Publisher Services and Distribution Configuration, Phase C application interfaces.
• Repository: thoth-pub/thoth-app only for authenticated publisher/staff UI and client behaviour.
• Risk: MEDIUM.
• Upstream compatibility baseline: thoth-pub/thoth release v1.7.0 at commit 40e9c06d4ab76217c3ef277dd539d3b5580e2bb8, tree 8797558959fcf1f418eb33ca080b469e97783cbd.
• Approved decomposition: APP-01A contract pin/read-only publisher configuration; APP-01B superuser editing/concurrency/error UX; APP-01C truthful latest back-catalogue job presentation.
• Backend remains authoritative for package capabilities, platform inventory/assignability/linkage normalization, authorization, configuration versioning and job lifecycle/state.
• Frontend must not create parallel domain policy, infer dissemination from configuration/job absence, change auth policy, activate job creation, perform migration work, or perform provider/runtime actions.
• Each child remains a separate bounded repository-local issue/branch/PR with its own exact authorized base SHA, scope, validation, independent exact-head review and merge authorization.

Gate result

SPECIFICATION APPROVED; IMPLEMENTATION REMAINS ON HOLD.

This approval satisfies the parent APP-01 specification-approval gate only. It does not authorize source modification or child implementation.

Remaining gates before APP-01A implementation authorization:

1. resolve BR-APP-01 by completion or durable CTO exception for the current dev -> feature/... -> dev topology;
2. resolve the app portion of CG-11, or record an explicit temporary readiness exception with compensating validation;
3. generate the exact v1.7.0 SDL using the canonical upstream generation path and record its SHA-256/provenance;
4. create and approve the APP-01A repository-local child specification against a fresh exact dev SHA;
5. issue separate explicit implementation/action authorization for that exact child/base/write budget.

No branch creation, source write, commit, push, PR mutation, manual CI, provider/runtime access, migration, release, merge, deployment or production activation is authorized by this comment.

[ja573]

CTO branch-readiness exception - APP-01

APP-01 branch-readiness is approved by exception for this task family.

For APP-01A, APP-01B and APP-01C, use the repository's current task topology:

dev -> feature/... -> dev

This exception is limited to APP-01 child work and does not normalize or otherwise change repository branch policy. BR-APP-01 remains separate deferred work.

Each child still requires:

• its own approved repository-local issue/specification;
• a fresh preflight against live dev;
• an exact authorized base SHA recorded before implementation;
• an independently bounded branch/PR;
• explicit implementation authorization;
• exact-head independent review before any merge authorization.

This exception does not authorize:

• branch normalization or changing dev/main topology;
• source/worktree modification;
• branch creation;
• commit or push;
• PR creation/update;
• CI workflow changes or manual CI actions;
• SDL generation/materialization or codegen changes;
• provider/runtime access or mutation;
• migration execution;
• merge;
• release/publication;
• deployment;
• production activation.

APP-01 therefore clears the BR-APP-01 readiness gate by explicit CTO exception, but remains HOLD on the other recorded prerequisites, including CI/readiness disposition, exact v1.7.0 SDL/digest control, and child-task specification/implementation authorization.

[ja573]

CTO temporary CG-11 readiness exception - APP-01A only

Decision: APPROVED EXCEPTION FOR APP-01A ONLY.

APP-01A may proceed through its remaining readiness/specification and later implementation-authorization gates before CTRL-APP-CI-01 / CG-11 is fully closed. This exception exists solely to break the dependency cycle by allowing APP-01A to establish the immutable exact v1.7.0 GraphQL contract input and then implement its already-approved bounded read-only publisher-configuration scope.

This exception does not apply to APP-01B or APP-01C. Those children remain HOLD on CG-11 closure unless a separate explicit CTO exception is recorded later.

Compensating validation required for APP-01A

Before APP-01A can receive merge authorization, its exact authorized base/head must have recorded evidence, as applicable, for:

npm ci
npm run generate   # against the exact pinned v1.7.0 SDL, not the moving test API
npm run lint
npm test -- --run --coverage
npm run build

In addition:

• the v1.7.0 SDL must come from the canonical upstream generation path at exactly thoth-pub/thoth @ 40e9c06d4ab76217c3ef277dd539d3b5580e2bb8;
• its SHA-256 and provenance must be durably recorded before generated-client compatibility is accepted;
• repeat generation from the same pinned SDL must be clean/deterministic, with any generated diff explicitly recorded;
• lint results must distinguish pre-existing repository debt from regressions introduced by APP-01A, using the approved no-new-debt direction recorded on thoth-pub/thoth-app#117;
• focused tests for the APP-01A changed modules remain required;
• independent review remains bound to the exact PR head SHA.

Authorization boundary

This comment clears only the CG-11 readiness prerequisite for APP-01A by temporary exception. It does not itself authorize APP-01A implementation.

Still separately required before source work:

1. exact v1.7.0 SDL generation/digest/provenance evidence under separately authorized work;
2. APP-01A repository-local child issue/specification;
3. fresh live dev preflight and exact authorized base SHA;
4. frozen branch/target/write budget and prohibited paths;
5. explicit implementation/action authorization.

This exception does not authorize SDL generation/materialization or codegen execution by itself, source/worktree modification, branch creation, commit, push, PR creation/update, CI workflow mutation or manual CI actions, provider/runtime access, migration, merge, release/publication, deployment or production activation.

[ja573]

APP-01A child specification and accepted schema evidence

Created repository-local child issue:

• APP-01A: APP-01A: Pin v1.7 contract and add read-only publisher service configuration #118 - Pin v1.7 contract and add read-only publisher service configuration
• observed app specification baseline: dev @ 7a4e7c6ceaec36fbdb201eaeb9ae36985a709889, tree 2ea8c49a1936dd25cbea74a749532a32bb6d8399
• implementation remains NOT AUTHORIZED; no implementation base SHA, branch or PR has been authorized

CTO-accepted v1.7.0 schema evidence

The CTO supplied and explicitly confirmed the attached live production schema.graphql as the live v1.7.0 contract and waived further source-generation/runtime comparison for this readiness gate.

Accepted artifact evidence:

• SHA-256: 521fba3b438c0013f21bfcbff62a24a3349cdd394738a40fd62e8f76fbf14226
• size: 177616 bytes
• line count: 4628
• required APP-01 surfaces confirmed, including publisherServiceConfiguration, distributionPlatformOptions, PublisherServiceConfiguration, effectiveCapabilities and enabled distribution-platform metadata/state

For APP-01A, the earlier additional canonical-source/runtime byte-comparison prerequisite is therefore superseded by this explicit CTO acceptance. The immutable implementation input is now identified by the exact SHA-256 above; a later/moving live schema must not silently replace it.

APP-01A implementation must materialize a repository-local schema snapshot with exactly that digest, switch codegen away from the moving api.test schema source, regenerate gql/, prove repeat generation clean, and then implement only the read-only publisher configuration scope defined in #118.

The existing APP-01 branch-readiness exception and APP-01A-only temporary CG-11 exception remain in force. APP-01B/APP-01C remain separate and are not authorized by this comment.

Current gate: APP-01A specification candidate exists at #118; CTO specification approval and a fresh exact-base implementation authorization remain required before any source, branch, commit, push or PR action.

No source/worktree change, schema materialization, branch creation, commit, push, PR mutation, manual CI, provider/runtime access, migration, merge, release, deployment or production activation is authorized by this comment.

[ja573]

APP-01 COORDINATION UPDATE - APP-01A MERGED

APP-01A (#118) has completed its source implementation and merge gate.

Exact merged state

• Child: APP-01A
• Owning issue: #118
• PR: #119
• Reviewed/authorized head: 8a9be2fc30d9db33b0d2b3b5eea653717aa52ce1
• Merge commit on dev: 27a7cc0de538a86041055dc72f8a0bc188ab3e3e
• Merge tree: b25c2aa09288980a5a45412cfa9ff8ab89fe97a5
• Current dev at reconciliation: 27a7cc0de538a86041055dc72f8a0bc188ab3e3e

The merge commit directly combines former dev@7a4e7c6ceaec36fbdb201eaeb9ae36985a709889 with the independently reviewed APP-01A head above.

Programme effect

The APP-01A merge establishes on dev the approved shared foundation for later APP-01 children:

• immutable local v1.7.0 SDL pin at approved digest 521fba3b438c0013f21bfcbff62a24a3349cdd394738a40fd62e8f76fbf14226;
• deterministic GraphQL codegen against that pinned contract;
• publisher service-configuration and distribution-platform option read surfaces;
• read-only Profile integration using backend-authoritative package/capability/platform state;
• publisher-scoped configuration query/cache identity.

APP-01A itself is therefore MERGED TO dev / SOURCE STAGE COMPLETE.

Remaining APP-01 children

APP-01B and APP-01C remain separate repository-local tasks. This merge does not authorize either child automatically.

Before either child implements:

1. create/confirm its dedicated owning issue and approved specification;
2. re-evaluate the live readiness dependencies, including the still-separate app CI/readiness control gap under #117 unless an explicit new exception is approved;
3. preflight the then-current live dev and bind implementation authorization to its exact SHA;
4. define the child-specific write budget, branch and PR target;
5. independently review the exact PR head before any merge authorization.

APP-01B remains responsible for superuser mutation, optimistic concurrency / structured error UX and job-creation-disabled failure handling. APP-01C remains responsible for truthful nullable latest back-catalogue job presentation. Neither scope is absorbed by APP-01A.

Release / activation boundary

Merge to dev is not release, deployment, migration or production activation. No such action is authorized by this coordination update.

Current APP-01 programme gate: APP-01A merged; APP-01B / APP-01C remain pending their own readiness/specification/implementation gates.

[ja573]

APP-01 readiness coordination - CTRL-APP-CI-01 resumed

APP-01A is merged to dev; current dev is:

27a7cc0de538a86041055dc72f8a0bc188ab3e3e

The immutable v1.7.0 codegen input established by APP-01A now exists on dev, so the codegen-input blocker previously holding CTRL-APP-CI-01 (#117) is cleared.

Fresh baseline measurement for #117 has been explicitly authorized in comment 5343106199, bound to exact dev@27a7cc0de538a86041055dc72f8a0bc188ab3e3e / tree b25c2aa09288980a5a45412cfa9ff8ab89fe97a5.

#117 implementation itself remains HOLD until that fresh baseline is returned, the final bounded mechanism/write budget is frozen, and separate implementation authorization is issued.

APP-01B and APP-01C remain separately gated and are not authorized for implementation by this coordination update. The preferred sequence remains:

APP-01A merged -> CTRL-APP-CI-01 readiness closure -> APP-01B -> APP-01C

No release, deployment, migration, provider action or production activation is authorized by this comment.

[ja573]

APP-01 coordination update - CG-11 implementation authorized

APP-01A remains merged to dev via PR #119 / merge commit 27a7cc0de538a86041055dc72f8a0bc188ab3e3e.

CTRL-APP-CI-01 (#117) has now completed its fresh post-APP-01A baseline at that exact dev SHA and the control plane has accepted/frozen the final bounded CI design in #117 comment 5343334474.

Current #117 gate: IMPLEMENTATION AUTHORIZED at exact base:

27a7cc0de538a86041055dc72f8a0bc188ab3e3e

Authorized implementation branch:

ci/ctrl-app-ci-01-readiness-gates

The CI task will add the no-new-debt lint ratchet, preserve tests/coverage, add production-build evidence, and add pinned-schema codegen consistency, with exact-head independent review before any merge authorization.

APP-01B and APP-01C remain HOLD for implementation until #117 is independently reviewed, merged and reconciled back to this coordination issue. No APP-01B/C source work is authorized by this comment.

No release, deployment, migration, provider action or production activation is authorized.

[ja573]

APP-01 COORDINATION UPDATE - CI/READINESS DEPENDENCY CLEARED

CTRL-APP-CI-01 / #117 has been independently reviewed, authorized, and merged.

PR: #120
Reviewed head: 050efbc0efbe35947b6a40d20bd0d32f9723a8b1
Merge commit / current dev: 2cd4f45e6664f18ffba4e6870c41f79cb16306d6

The merge is reconciled on #117 in comment 5346407288.

Programme effect

The temporary CI/readiness condition that constrained APP-01B and APP-01C is now cleared: merged dev contains the immutable v1.7 schema/codegen foundation from APP-01A and the no-new-debt lint, tests/coverage, production-build, and codegen-consistency GitHub CI controls from CTRL-APP-CI-01.

Next gates

APP-01B and APP-01C are not automatically implementation-authorized by this merge. Each still requires a fresh current-dev preflight, bounded child specification/write budget, exact authorized base SHA, implementation handoff, exact-head independent review, and separate merge control.

Recommended sequence remains APP-01B first, then APP-01C unless a fresh dependency/scope review supports safe parallelism.

No release, deployment, migration, provider mutation, or production activation has been authorized or performed by this coordination update.

[ja573]

APP-01B CHILD SPECIFICATION CREATED

Repository-local child issue created:

• APP-01B: APP-01B: Add superuser publisher service-configuration editing and concurrency/error UX #121 - superuser publisher service-configuration editing and concurrency/error UX
• repository: thoth-pub/thoth-app
• risk: MEDIUM
• current observed dev: 2cd4f45e6664f18ffba4e6870c41f79cb16306d6
• tree: 27c1bbca1d8facce65e5221065f835256fe11f18

Prerequisite reconciliation:

• APP-01A / APP-01A: Pin v1.7 contract and add read-only publisher service configuration #118 / PR Add read-only publisher service configuration to Profile (APP-01A) #119: merged to dev;
• CTRL-APP-CI-01 / CTRL-APP-CI-01: Close thoth-app CG-11 CI readiness gap #117 / PR CTRL-APP-CI-01: Lint, build and codegen readiness gates for GitHub CI #120: merged and reconciled; CI/readiness dependency is cleared;
• APP-01 branch-readiness exception comment 5330071385 remains applicable to APP-01B;
• pinned v1.7.0 SDL remains the contract baseline with SHA-256 521fba3b438c0013f21bfcbff62a24a3349cdd394738a40fd62e8f76fbf14226;
• no open PR currently overlaps APP-01B and no APP-01B branch existed at specification preflight.

The child specification records the released backend's exact structured GraphQL error shape: publisher-service classifications are in extensions.type, including STALE_SERVICE_CONFIGURATION and DISTRIBUTION_JOB_CREATION_DISABLED. It also records the exact replace input/version semantics, backend-authoritative linked normalization, assignability handling, server-normalized success state and no-auto-retry failure behaviour.

Current APP-01B gate: SPECIFICATION CANDIDATE / IMPLEMENTATION HOLD.

Still required before implementation:

1. CTO approval of APP-01B: Add superuser publisher service-configuration editing and concurrency/error UX #121's child specification;
2. fresh live dev/tree/overlap/branch preflight;
3. exact authorized implementation base and frozen write budget;
4. explicit implementation authorization/handoff.

APP-01C remains a separate child and is not authorized by this update.

No source, branch, PR, manual CI, provider, merge, release, deployment, migration or production activation action was performed.

[ja573]

APP-01 COORDINATION UPDATE - APP-01B IMPLEMENTATION AUTHORIZED

APP-01B is now the active implementation stage.

• Child issue: APP-01B: Add superuser publisher service-configuration editing and concurrency/error UX #121
• CTO specification approval: APP-01B: Add superuser publisher service-configuration editing and concurrency/error UX #121 comment 5346533126
• Fresh exact-base implementation authorization: APP-01B: Add superuser publisher service-configuration editing and concurrency/error UX #121 comment 5346560179
• Authorized base: dev@2cd4f45e6664f18ffba4e6870c41f79cb16306d6
• Base tree: 27c1bbca1d8facce65e5221065f835256fe11f18
• Authorized branch: feature/app-01b-publisher-service-configuration-editing
• Risk: MEDIUM

Dependencies are satisfied: APP-01A is merged and CTRL-APP-CI-01/#117 is merged/reconciled. Fresh preflight found no open overlapping PR and no APP-01B branch.

APP-01B remains bounded to superuser service-configuration editing, optimistic-concurrency/error UX and the narrow structured GraphQL error-preservation change. Backend authorization, normalization, configuration-version semantics and durable-job behavior remain authoritative.

APP-01C remains separate and is not authorized by this update.

Next gate for APP-01B:

implementation -> draft PR -> independent exact-head review -> CTO merge authorization -> merge to dev

No merge, release, deployment, migration, provider action or production activation is authorized by this coordination record.

[ja573]

APP-01 COORDINATION UPDATE - APP-01B CHANGES REQUIRED

APP-01B / #121 has completed its first independent exact-head review on PR #122 at head 069cf6e6c92a3838c6398e5d3ecded01d997dcff.

Decision: CHANGES REQUIRED.

Two blocking client-correctness findings must be remediated on the existing authorized APP-01B branch before a fresh exact-head review:

1. bind/reset the service-configuration edit session across active-publisher changes so state/token from publisher A can never be submitted using publisher B's ID, including safe cache/refetch binding during an in-flight mutation;
2. reconcile protected configuration and reset the failed edit session after unclassified/network mutation failures so displayed state returns to server truth before another edit.

The corrections fit the existing #121 write budget and do not require a scope expansion. Current dev remains 2cd4f45e6664f18ffba4e6870c41f79cb16306d6; exact-head CI for the reviewed head is green, but CI success does not override the blocking source findings.

APP-01B remains unmerged. APP-01C should not consume or guess APP-01B changes while remediation/review is outstanding.

No merge, release, deployment, migration, provider action or production activation is authorized by this coordination record.

[ja573]

APP-01 coordination - APP-01B remediation review

APP-01B PR #122 has been freshly independently reviewed at exact head ecb402949ea9d6c40d64a74a3d907eda0e93d7e8.

Current APP-01B gate: HOLD - SOURCE REMEDIATION ACCEPTED / CI RECONCILIATION REQUIRED.

The two prior source findings are remediated and no remaining blocking source defect was identified. The remediation stayed within its four-path authorization.

Exact-head CI evidence conflicts on the identical SHA: pull-request run 32348183325 is green, while push run 32348178940 is red on an unrelated PreviewStep.test.tsx timing failure outside APP-01B's changed paths. This is consistent with a flaky unrelated test, but authoritative CI must be reconciled before APP-01B can move to source approval / merge readiness.

PR review record: 4980729982
#121 ledger record: 5353532719

APP-01C remains downstream/separately gated. No mark-ready, merge, manual CI rerun, release, provider action, migration, deployment or production activation is implied.

[ja573]

APP-01 coordination update - APP-01B exact-head approval complete

APP-01B child: #121
PR: #122
Exact approved head: ecb402949ea9d6c40d64a74a3d907eda0e93d7e8
Current dev: 2cd4f45e6664f18ffba4e6870c41f79cb16306d6

The APP-01B source remediation is independently approved at this exact head. The CI reconciliation HOLD is cleared after Actions run 32348178940 attempt 2 completed SUCCESS on the same SHA.

APP-01B current gate: AWAITING CTO MERGE AUTHORIZATION.

APP-01C remains a separate downstream child/stage and is not implementation-authorized by this update. No deployment, migration, release or production activation is authorized here.

[ja573]

APP-01B merge reconciliation / APP-01C next gate

APP-01B is now merged and the repository-local child is complete.

• child issue: APP-01B: Add superuser publisher service-configuration editing and concurrency/error UX #121 (closed completed)
• PR: Add superuser publisher service-configuration editing and concurrency/error UX (APP-01B) #122 (closed/merged)
• independently approved source head: ecb402949ea9d6c40d64a74a3d907eda0e93d7e8
• previous dev: 2cd4f45e6664f18ffba4e6870c41f79cb16306d6
• merge commit / current dev: 2c6ad100ae713b5d50e8bb57a861d5cf5cc41813
• merge tree: 5216524990790b5e5189f22315a61c8b2a47e54c
• merge parents: previous dev + approved APP-01B head
• merge commit signature: verified

The APP-01B source gate is therefore reconciled. Merge does not imply deployment, release, provider mutation, migration or production activation.

Next application child gate: APP-01C specification/current-dev preflight for truthful latest back-catalogue job presentation. No APP-01C source implementation is authorized by this coordination record.

[ja573]

Control-plane incident correction before APP-01C

During APP-01C specification setup, two unintended direct commits were accidentally created on dev by misuse of a GitHub connector action. They were not part of any approved source task:

• 780292e0a1e99d2dc3b1440dda56f349fcb11030 - created only __DO_NOT_CREATE__;
• e4abd02350fc4b1e87e017133a4a97f8b8270e14 - created only NOPE.

The CTO explicitly authorized correction without history rewriting.

Correction performed:

• corrective commit: 31ca3555394cc8bf40796e986654f8b100b1ccbf;
• parent: e4abd02350fc4b1e87e017133a4a97f8b8270e14;
• corrective tree: 5216524990790b5e5189f22315a61c8b2a47e54c;
• dev fast-forwarded normally to the corrective commit;
• that tree is exactly the clean tree of APP-01B merge commit 2c6ad100ae713b5d50e8bb57a861d5cf5cc41813;
• both accidental files are therefore absent from current dev;
• the accidental commits remain in history for auditability; no force-push/history rewrite was used.

Current repository baseline for subsequent APP-01C control work is therefore:

dev @ 31ca3555394cc8bf40796e986654f8b100b1ccbf

tree:

5216524990790b5e5189f22315a61c8b2a47e54c

This comment is incident/reconciliation evidence only. It does not authorize APP-01C source implementation, branch creation, PR creation, merge, provider actions, release, deployment, migration, job activation or production activation.