Story Mode: provider-neutral Local / Cloud / Hybrid routing with Ollama connections

[BryanHarrisScripts]

Developer Brief

Objective

Generalize the current Cloud Story Mode settings into one provider-neutral Story Mode surface with three PlotPickle execution policies:

[L] LOCAL
[C] CLOUD
[H] HYBRID

Ollama should be represented as a provider family with distinct local and cloud connection routes behind those policies. Local / Cloud / Hybrid are PlotPickle execution modes, not Ollama product modes.

This is a focused settings/routing clarification. Reuse the existing provider/capability routing architecture and current Cloud Story Mode behavior. Do not create a second provider system, a new orchestration engine, or duplicated settings pages.

---

Product decision

Story Mode is the user-facing concept

The parent surface should become:

SETTINGS / STORY MODE

rather than making Ollama itself the product-level mode.

The user chooses one of three PlotPickle policies:

• LOCAL — use enabled local-capable providers/runtimes.
• CLOUD — use explicitly enabled/consented cloud connections.
• HYBRID — allow both Local and Cloud routes according to capability, availability and routing preference.

Ollama remains replaceable infrastructure behind that boundary.

---

Target settings structure

Story Mode landing surface

Use the existing Matrix / BBS keyboard language:

[L] LOCAL   - Local-first Story compute and generation
[C] CLOUD   - Explicit cloud Story connections
[H] HYBRID  - Route across Local and Cloud capabilities

Do not build three separate application shells. Reuse the current Cloud Story Mode surface as the Cloud destination and add only the minimum Local/Hybrid equivalents needed.

LOCAL

Expose local Story capabilities and connections.

Initial connection of interest:

[O] Ollama - Local LLM/runtime for supported Writing and Agent compute

Where existing architecture supports it, Local may also surface other established local-capable runtimes such as local ComfyUI without creating a new provider registry.

Ollama Local configuration may expose only useful operational facts already available or safely detectable, such as:

• availability / connection state;
• local endpoint;
• installed/available models where existing APIs permit;
• model capability/context information where reliable;
• relevant hardware/runtime readiness.

Do not require Ollama for Local Story Mode. Ollama is one local connection, not the definition of Local.

CLOUD

Preserve the current Cloud Story Mode capability model and consent boundary.

Existing cloud connections remain valid, including where supported:

• OpenAI;
• remote ComfyUI;
• Gemini;
• MiniMax;
• other existing reviewed cloud providers.

Add Ollama Cloud as a cloud connection for supported Writing / Agent compute where the existing routing/capability contracts can represent it truthfully.

The connection should be described as Ollama Cloud, not as a separate “Ollama Cloud Story Mode.”

Cloud routes remain explicit and consented. Paid/remote routes must not be silently activated.

HYBRID

Hybrid is a routing policy, not another provider connection.

Do not create “Ollama Hybrid.” Hybrid consumes whatever Local and Cloud connections are already enabled.

Initial Hybrid UI should remain small. It may expose a bounded routing preference such as:

Prefer Local
Best Available
Prefer Cloud

along with existing consent/fallback behavior where already supported.

Hybrid must reuse the canonical routing/capability resolver rather than adding Hybrid-specific provider selection logic.

---

Status model

Support a compact derived Story Mode status such as:

LOCAL: READY
CLOUD: READY
HYBRID: READY
MODE: LOCAL

These are derived operational states, not manually configured flags.

Suggested semantics:

• LOCAL: READY — at least one usable enabled local route satisfies the relevant Story capability contract.
• CLOUD: READY — at least one usable, consented cloud route is available.
• HYBRID: READY — both usable Local and Cloud routes are available to the routing policy.
• MODE — the active PlotPickle Story Mode policy: LOCAL / CLOUD / HYBRID.

Do not imply a provider is usable merely because it is installed or listed. Readiness should follow existing capability/availability truthfulness.

---

Ollama architecture boundary

Recent Ollama desktop releases expose Apps / ollama launch integrations for external coding and agent clients such as Claude Code, Codex CLI, OpenCode, Pi, Cline, Qwen Code, DeepSeek Harness and others.

That is useful evidence that Ollama increasingly acts as a model/runtime socket for interchangeable external harnesses, but this issue does not turn those applications into Story Mode providers or new PlotPickle product Agents.

Keep the two lanes separate:

PlotPickle product Agent / Story task
→ PlotPickle routing + capability resolution
→ Local / Cloud provider connection
→ Ollama or other selected runtime/model

versus developer tooling:

Pi / Cline / Codex / Claude Code / other developer harness
→ Ollama or another model backend
→ PlotPickle repository work

Developer agents remain governed by the repository development contract and are not part of Story Mode simply because Ollama can launch them.

---

Architectural rule

Do not introduce “Multiplexer” as a new PlotPickle subsystem for this work.

The useful behavior is already Routing / Capability Resolution:

Story task requirement
→ capability resolver
→ active Story Mode policy
→ eligible Local / Cloud route
→ provider/runtime/model

The provider and model remain replaceable.

PlotPickle owns:

• Story Mode policy;
• capability requirements;
• routing/selection policy;
• consent boundaries;
• Story/PPF authority.

Providers such as Ollama, OpenAI, Gemini, MiniMax or ComfyUI supply capabilities but do not become creative authority.

---

Preserve authority boundaries

This settings work must not alter canonical creative ownership.

Maintain the distinction:

Model ≠ Agent ≠ Harness ≠ Provider ≠ PPF

PPF / Human-approved PlotPickle state remains canonical creative truth.

Story Mode only decides where eligible compute executes. It must not decide what becomes canon.

This also aligns with:

• Provider-neutral Universal Creative Transaction Contract #2035 — safe creative transaction / verification / Human review / commit boundary;
• Pre-production Production Object Layer: Story → Frames progressive authoring architecture #2092 — provider-neutral Production Object Layer and Human-facing production state;
• Provider-neutral Director Spec Compiler #2064 — provider-neutral Director Spec Compiler and disposable provider-specific instructions.

Do not duplicate any of those responsibilities here.

---

Reuse boundary

Before adding new schemas or registries, inventory and reuse current:

• Cloud Story Mode settings surface;
• Local AI/runtime settings;
• AI provider/source registry;
• capability routing/resolution;
• Agent compute defaults/overrides;
• provider diagnostics/readiness;
• local/cloud consent controls;
• Ollama detection/configuration already present in PlotPickle;
• existing ComfyUI local/remote distinctions.

Prefer adapting the current surfaces/contracts over creating new ones.

---

Initial implementation scope

In scope:

• rename/generalize the parent concept from Cloud Story Mode to Story Mode;
• Local / Cloud / Hybrid keyboard directory;
• preserve current Cloud capabilities/connections;
• add Ollama as a Local connection where supported by existing local runtime architecture;
• add Ollama Cloud as a Cloud connection where capability truth can be represented correctly;
• small Hybrid routing-policy surface using the existing resolver;
• derived LOCAL / CLOUD / HYBRID readiness and active MODE status;
• keyboard-first Matrix/BBS consistency;
• focused regression coverage for routing-policy selection and readiness derivation.

Out of scope:

• building a new provider registry;
• creating an Ollama-specific Story architecture;
• creating “Ollama Hybrid”;
• duplicating Local/Cloud provider settings across three independent pages;
• automatically enabling paid cloud routes;
• auto-installing or auto-launching external Ollama Apps;
• adding Claude Code, Codex, Pi, Cline, Hermes, OpenClaw, etc. as Story Mode Agents merely because Ollama can launch them;
• replacing existing Agent compute/routing contracts;
• changing PPF/canon authority;
• redesigning unrelated Settings surfaces.

---

Acceptance criteria

1. The user-facing parent concept is Story Mode, not Ollama Story Mode.
2. Story Mode exposes LOCAL / CLOUD / HYBRID as PlotPickle execution policies.
3. Existing Cloud Story Mode behavior and consent boundaries are preserved under CLOUD.
4. Ollama can appear as an eligible Local connection without becoming mandatory for Local Story Mode.
5. Ollama Cloud can appear as a Cloud connection where supported, without becoming its own Story Mode.
6. HYBRID reuses enabled Local + Cloud connections and the canonical capability resolver; no separate Hybrid provider layer exists.
7. No “Ollama Hybrid” connection is created.
8. LOCAL / CLOUD / HYBRID readiness values are derived from actual usable routes/capabilities rather than manually set.
9. Active MODE is visible and reports LOCAL / CLOUD / HYBRID.
10. Cloud routes continue to require explicit connection/consent where current policy requires it.
11. External Ollama Apps / coding harnesses are not silently promoted into PlotPickle product Agents or Story providers.
12. Existing PPF, Provider-neutral Universal Creative Transaction Contract #2035 transaction, Pre-production Production Object Layer: Story → Frames progressive authoring architecture #2092 Production Object, Provider-neutral Director Spec Compiler #2064 compilation and Agent authority boundaries remain unchanged.
13. No parallel provider registry, routing engine or duplicated Story settings architecture is introduced.
14. Implementation remains small, provider-neutral and compatible with future Local and Cloud providers beyond Ollama.

---

Implementation discipline

Keep this conservative. First inventory the current Cloud Story Mode, Local AI, provider routing and Ollama boundaries. Reuse existing contracts and UI primitives. Add only the minimum missing Story Mode policy layer and Ollama connection representations needed to express the agreed architecture.

The goal is not to make Ollama the center of PlotPickle. The goal is to let PlotPickle use Ollama cleanly as one replaceable Local/Cloud provider family behind a stable Story Mode boundary.

[BryanHarrisScripts]

Addendum — Job-based routing preferences

Keep the existing Capabilities model intact. Add a separate, additive JOB ROUTING / JOB PREFERENCES panel under each Story Mode policy so the user can understand and optionally control the principle: appropriate model/provider based on the job.

This does not replace Local / Cloud / Hybrid. Those remain the PlotPickle execution policies. Job Routing operates inside the active policy.

Suggested job classes

[W] Writing
[D] Images — Fast / Draft
[P] Images — Precision / Edit
[V] Video
[A] Agents

Preserve Video even though the immediate trigger for this clarification is the new OpenAI image model split. Do not regress the existing Writing / Images / Video / Agents capability structure.

Separation of concerns

Capabilities answers:

What can this mode/provider do?

Job Routing answers:

For this kind of work, where should PlotPickle send it?

Do not merge those concepts into one settings list.

Routing flow

Job type
→ required capability contract
→ active LOCAL / CLOUD / HYBRID policy
→ eligible provider routes
→ appropriate provider/model

The user should be able to leave each job on AUTO or optionally set a preference. The setting is a routing preference, not a new creative authority.

Example presentation

Writing                    AUTO → Ollama / selected writing model
Images — Fast / Draft      AUTO → suitable fast/draft image route
Images — Precision / Edit  AUTO → suitable precision/edit image route
Video                      AUTO → suitable video route
Agents                     AUTO → suitable agent-compute route

Provider/model names shown after AUTO are current resolution results, not hard-coded architectural assignments.

LOCAL

Only Local-eligible routes may resolve.

If a job has no suitable Local route, show it truthfully as unavailable or fallback-disabled according to current policy. Do not imply support merely because a provider is installed.

CLOUD

Only enabled/consented Cloud routes may resolve.

For example, a cloud image provider may expose separate fast/draft and precision/edit capabilities behind one connection. PlotPickle should route by capability rather than force the user to know model names for ordinary work.

HYBRID

Hybrid is where per-job preference becomes most useful. Support a small bounded preference set such as:

AUTO
LOCAL FIRST
CLOUD FIRST
PINNED PROVIDER

A user may therefore choose different policies by workload, for example:

Writing                    LOCAL FIRST
Images — Fast / Draft      LOCAL FIRST
Images — Precision / Edit  CLOUD FIRST
Video                      LOCAL FIRST
Agents                     AUTO

This is more precise than one global Prefer Local switch because different jobs legitimately have different best execution paths.

OpenAI Images 2.5 example, not hard-coding

The current OpenAI Images 2.5 family is a useful example of why job-based routing matters: a fast/draft image task may resolve to a lower-latency image model, while a precision/edit task may resolve to a higher-control model. PlotPickle should represent the capability distinction, not hard-code those model names into Story Mode architecture.

Useful capability concepts may include:

FAST_VISUAL_DRAFT
PRECISION_VISUAL_EDIT
REFERENCE_PRESERVING_EDIT
TRANSPARENT_ASSET

Use existing capability contracts where possible; introduce only the minimum missing distinctions if the current model cannot express them.

Authority rule

Job Routing decides where eligible compute executes. It does not decide what becomes canon.

Maintain:

Model ≠ Agent ≠ Harness ≠ Provider ≠ PPF

PPF / Human-approved state remains canonical creative truth.

Scope guard

This addendum is additive to #2106. Do not create:

• another provider registry;
• a second capability resolver;
• a model-specific Story Mode page;
• separate duplicated routing screens for every provider;
• hard-coded OpenAI/Ollama job ownership.

The goal is a clearer user-facing layer over the existing routing architecture: choose the execution policy, then let PlotPickle select the appropriate route for the job unless the user overrides it.

[BryanHarrisScripts]

#2106 implementation checkpoint — policy boundary first

Current-state audit confirms the existing architecture already owns provider capability/readiness and Local/Cloud locality through /api/ai-routing, Writing Assistant stores, Media Routing and native ComfyUI/H3 state. There is no separate canonical capability resolver to duplicate.

Slice A decision

Implement Story Mode first as a thin execution-policy boundary over the existing selected routes:

• LOCAL permits Local execution and blocks selected Cloud execution.
• CLOUD permits Cloud execution and blocks selected Local execution.
• HYBRID preserves current behavior and permits either locality.
• default is HYBRID for backward compatibility until the Human chooses another policy.
• off / manual remain neutral rather than being treated as providers.
• unknown route locality fails closed.
• the policy does not alter PPF/canon, provider setup, provider credentials, paid-cloud consent, Agent authority or the existing route stores.

The guard reads the actual active Writing provider rather than trusting the older routing-choice snapshot, because hardware-aware local text execution can exist outside that older TextRoute union.

Deferred within #2106 — do not fake these

1. Parent Story Mode Settings directory + derived readiness — next slice, reusing the existing Local and Cloud hosts.
2. Job Routing preferences — current router has one image selection and current generation requests do not yet carry a Fast/Draft vs Precision/Edit job identity. Adding a preference UI before that seam exists would be decorative rather than real routing.
3. Ollama Cloud — current ollama provider profile is explicitly Local. A cloud Ollama row would be false capability metadata until a distinct remote connection/auth/runtime route exists.

This keeps #2106 provider-neutral and avoids creating a second routing system.

[BryanHarrisScripts]

#2106 implementation checkpoint — Story Mode surface merged

PR #2122 is merged as squash commit d8e488f39fb9f28b5d99fcd4070b0ec5bc4a1085.

This second bounded slice adds the user-facing Story Mode surface without creating a second routing/provider system:

• Settings now exposes one [S] Story Mode destination instead of separate Local/Cloud rows.
• Story Mode exposes [L] LOCAL, [C] CLOUD, [H] HYBRID.
• Local reuses the existing LocalAiSkinHost; Cloud reuses the existing CloudStoryModeHost; Hybrid remains a small routing-policy view.
• Derived readiness reuses existing /api/ai-routing/status plus /api/local-ai/runtime; Ollama is not required to define Local readiness.
• Selecting Local/Cloud/Hybrid opens the configuration surface immediately, while the active execution policy changes only after the existing Story Mode policy authority confirms the write.
• Existing Cloud consent/provider boundaries remain unchanged.
• Local/Cloud child visual surfaces were moved from locked to candidate because Story Mode: provider-neutral Local / Cloud / Hybrid routing with Ollama connections #2106 intentionally changes their navigation shell (Back to Story Mode); the existing 2% tolerance and approved baseline images were not weakened or silently replaced.

Architecture Verification run #316 passed 7/7 layers on the final PR head.

Still deferred within #2106, per the earlier checkpoint rather than faked in this slice:

1. Job Routing / per-job preferences, until generation requests carry the required job identity/capability seam.
2. Ollama Cloud, until a truthful distinct remote connection/auth/runtime route exists.

No PPF/canon, #2035 transaction, #2092 Production Object, #2064 compilation, Agent authority, provider registry, or parallel capability resolver changes were introduced.

[BryanHarrisScripts]

#2106 next slice — real image job identity, no preferences UI yet

Current main already carries image request intent through quality plus reference/continuity fields, but the routing layer does not name that intent as a job class. The next bounded slice will reuse that existing request shape to establish two provider-neutral image job identities:

• image-fast-draft
• image-precision-edit

Compatibility rule: existing callers remain valid. Explicit job identity may be supplied, otherwise the gateway derives it from the current request intent (high-quality or reference/identity-preserving work resolves to precision/edit; ordinary low/medium generation resolves to fast/draft).

This slice will carry the resolved job identity through the real /api/local-ai/generate/image path and return it with the generation result so later Job Routing can consume a real execution seam.

Still out of scope for this slice:

• Job Routing preference UI or persistence;
• automatic route/provider switching;
• new provider registry/resolver;
• Ollama Cloud representation;
• PPF/canon/Agent authority changes.

This is groundwork for the existing #2106 Job Routing addendum, not a second routing system.

[BryanHarrisScripts]

#2106 checkpoint — real image job identity seam merged

PR #2123 is merged as 4e7b2404a30744f8905ecc3f74df1bacad514655.

This slice establishes one shared provider-neutral image job identity across the existing image execution paths:

• image-fast-draft
• image-precision-edit

Existing callers remain compatible. If no explicit job class is supplied, the gateway derives intent from the existing request shape: high-quality or reference / identity / continuity-preserving work resolves to Precision/Edit; ordinary low/medium generation resolves to Fast/Draft.

Both cloud image generation and local ComfyUI return the resolved jobClass, so normal media routing and the Ollama+ComfyUI path now expose the same real execution seam.

No preference UI, persistence, provider pinning, automatic route switching, new router/provider registry, Ollama Cloud representation, or PPF/canon/Agent authority change was introduced.

Architecture Verification run #318: all 7 layers green. The initial #317 failure was only fail-closed ownership mapping for the three pre-existing media-provider files; those files are now narrowly owned by Provider Runtime.

Remaining #2106 work stays bounded: consume this real job identity in Job Routing resolution/preferences when implemented; Ollama Cloud remains deferred until a truthful remote connection/auth/runtime contract exists.

[BryanHarrisScripts]

Downstream relationship to #2125 and #2064

#2125 now defines the Human-facing pre-production visual workflow, and #2064 remains the downstream Director Specification compiler.

Keep Story Mode's responsibility separate:

Human approves production intent in #2125
→ #2064 compiles provider-neutral Director Specification
→ required capabilities/job identity are known
→ #2106 applies LOCAL / CLOUD / HYBRID policy and job-routing preference
→ eligible provider/runtime executes

#2106 should not own Scene/Beat/Shot/Frame state or Director Specification semantics. It decides where eligible compute runs after the creative/production intent has already been established.