What is wrong-account prevention?
Before publish execution, Cenelira validates the persisted destination account against the schedule's workspace and platform, and refuses when that binding is missing or invalid.
Destination refusal
How Cenelira refuses invalid publish targets.
Before publish execution, Cenelira validates the persisted connected account for the platform inside the active workspace. If that binding is missing, deleted, cross-workspace, or on the wrong platform, the schedule is refused with a typed reason.
During account selection, the server can auto-resolve one clear account. When more than one matching account exists, it refuses instead of choosing. This page separates those paths and names the proof fields that record the destination when publish is allowed.
Where is the refusal enforced?
Inside the target identity flow. Selection can auto-resolve one clear account. Persisted schedule execution requires an exact connectedAccountId and returns HTTP 409 with a typed reason when the target needs repair.
What is out of scope?
This is a publish-path refusal. It does not re-authenticate the platform user at publish time, and it does not audit posts that predate the connection.
Who this is for
Built for operators who already know how this fails.
The refusal surface earns its rent in workspaces where more than one account, workspace, or platform can plausibly be picked. It has less value when there is only one of each.
For
- Agency operators publishing for multiple client workspaces where a cross-workspace slip would be visible to the client.
- Brand teams with more than one handle per platform (for example, a corporate handle and a product handle) who want the system to refuse when the account is ambiguous.
- Ops leads who have already seen a post go to the wrong account and who want the refusal enforced in code rather than in process documents.
Not for
- Solo operators with exactly one handle per platform. The resolver auto-resolves silently in that case, and the value of this page to you is lower.
- Teams that want fuzzy routing or "just pick one" behavior. Cenelira refuses instead of choosing.
- Workflows that want publish attempted even when the destination is unverified. This page is about publish-path refusal, not best-effort publish.
Mechanism
Two target checks. Six repair reasons. HTTP 409 target_repair_required.
The target identity flow lives in src/lib/schedules/targetIdentity.ts. resolveConnectedAccountForPlatformSelection handles account choice and can auto-resolve one clear candidate. resolveScheduleTargetIdentity validates the persisted schedule target before execution. Repair cases use ScheduleTargetIdentityError with HTTP 409 and the shared error code target_repair_required.
- connected_account_required
At execution, the persisted schedule carries no connectedAccountId. The publish path refuses instead of choosing a destination.
409 target_repair_required - connected_account_not_found
The saved connectedAccountId points at a row that no longer exists.
409 target_repair_required - connected_account_wrong_workspace
The saved account row exists but belongs to a different workspace than the schedule. Cross-workspace delivery is refused.
409 target_repair_required - connected_account_wrong_platform
The saved account row exists but is bound to a different platform than the schedule.
409 target_repair_required - connected_account_missing_for_platform
No connected account exists for this workspace and platform. The caller did not pass one, and the workspace has none.
409 target_repair_required - connected_account_ambiguous_for_platform
Two or more connected accounts match the workspace and platform, and the caller did not specify which one. The resolver refuses instead of choosing.
409 target_repair_required
Proof artifact
The proof record shows the server-side destination state.
When proof exports are generated, the record uses schedule and connected-account state from the server. There is no separate marketing copy for the destination; the value is read from stored publish data.
Two columns in the 17-field proof record carry the resolved destination:
targetAccount stores the server-resolved label of the destination account. It is derived from the schedule's ConnectedAccount relation, not from caption text.
platform stores the platform identifier on the schedule. The export does not rerun target repair; it records the server-side schedule and account state for schedules in the selected range.
The signed PDF and CSV twin both carry these columns. See the proof record schema for the full 17-field inventory and the signing primitives.
What this does not claim
Honest limits on the refusal surface.
A publish-path refusal is one gate in a larger system. This page is explicit about where the gate stops.
- Connection hygiene is enforced at publish time. The resolver does not re-verify the human who connected the account during OAuth.
- The resolver uses the external account id and label the platform returned at connection time. It does not re-authenticate the platform user on every publish.
- Solo workspaces with exactly one account per platform auto-resolve silently. The refusal surface fires when an exact binding is ambiguous or absent.
- The scope is publish-path authorization and the proof record. This page does not claim retroactive audit of posts that were made before Cenelira was connected to the account.
- External reviewer identity is a separate concern. Wrong-account prevention runs independently of whether the reviewer was internal or external.
FAQ
Short answers for operators.
What exactly does Cenelira refuse?
Six typed target-repair reasons, all returned as HTTP 409 target_repair_required across selection and execution paths: connected_account_required, connected_account_not_found, connected_account_wrong_workspace, connected_account_wrong_platform, connected_account_missing_for_platform, and connected_account_ambiguous_for_platform.
I have two accounts on the same platform in one workspace. What happens?
The resolver returns connected_account_ambiguous_for_platform when the caller did not specify which account to use. The schedule cannot move forward until an exact account is chosen.
What if a connected account was removed after the schedule was created?
The resolver returns connected_account_not_found and the schedule needs target repair before review or publish.
Does this cover external reviewers?
No. External reviewers approve a content version on a review link. Wrong-account prevention is a publish-path check. The two gates are independent and both run.
Where does the proof record show the destination?
In the targetAccount and platform columns of the signed proof export. They are produced from server-side schedule and connected-account state, not from caption text or buyer-written copy.
Last reviewed 2026-04-24
Get notified when the wrong-account prevention checklist ships.
A short checklist on how to set up workspace and account bindings so the refusal surface cannot drift. Leave an email and we will send it when the checklist is ready.