Alerts
The Alerts banner on Desktop surfaces actionable issues across your whole project. It sits above the activity feed on the right side of the main view and it sorts by severity — errors first, warnings second, info third. Each alert has a title, a detail snippet, and a link that takes you directly to the source of the problem in whichever module owns it. Click a broken-promise alert and you land on the Plot Studio view for that plotline with the promise highlighted. Click a lore-contradiction alert and you land on the Lorekeeper panel. Alerts are not notifications, not a history log, and not a stream of informational updates. They’re a focused list of things in your project that are currently broken and deserve attention.
The four alert types
Section titled “The four alert types”Broken promise (error severity)
Section titled “Broken promise (error severity)”Triggered when a narrative promise has been marked “broken” in your Plot Studio. A broken promise is the most severe alert Desktop ships because it represents a concrete bug in the narrative — the author made a commitment to the reader that the story failed to deliver on. Maybe a character was promised a resolution that never came. Maybe a mystery was set up but the reveal was cut. Maybe the climactic confrontation was rewritten into something that doesn’t match the setup.
Whatever the source, a broken promise is the kind of thing that a careful beta reader is going to notice and flag, and the kind of thing that an early review is going to complain about, and the kind of thing a future draft-editor is going to spot in your manuscript. Desktop wants you to see it before any of them do.
Orphan plant (warning severity)
Section titled “Orphan plant (warning severity)”Triggered when a plant has been marked “orphaned” in Plot Studio. A plant is something the narrative sets up for a later payoff — a gun on the mantelpiece, a secret identity, a mysterious scar, a missing parent. A plant becomes an orphan when the payoff never happens. You planted the gun in chapter two and never fired it. You showed the scar in chapter four and never explained it. You introduced the missing parent in chapter one and they never returned.
Orphan plants are a warning instead of an error because sometimes they’re intentional — you might plant a detail specifically to be ambiguous, and decide later that the ambiguity is the point. But most orphan plants are unintentional — you forgot about them during the draft, or you changed direction and didn’t go back to clean up. The alert exists to make sure you notice before the book is done.
Lore contradiction (warning severity)
Section titled “Lore contradiction (warning severity)”Triggered when the Lorekeeper detects an unresolved lore contradiction between a document and your Legendry. Maybe a character’s eye color was different in chapter two than in chapter eight. Maybe a city’s founding date doesn’t match across two different mentions. Maybe a species is described as having three fingers in the Legendry and four in a manuscript. Whatever the specific contradiction, it sits on the alerts banner until you either fix the source or mark the contradiction as resolved.
Lore contradictions are a warning rather than an error because they’re almost always fixable, and because a contradiction sometimes represents a character’s mistaken perception rather than a canonical error. The alert points you at the specific conflict so you can make the call.
ProseGuard (reserved)
Section titled “ProseGuard (reserved)”This alert type is reserved for future prose-quality flags from ProseGuard — flagged dialogue tags, banned Machine Tells, filter words, or other style violations that cross a severity threshold. It’s not wired up yet in this version of Ishvana, but the alert slot exists so the feature can land without a schema change. When it’s live, it’ll surface the same way as the other three.
Severity order and sort
Section titled “Severity order and sort”Alerts display sorted by severity, then by the book they belong to. Within each severity tier, books are ordered alphabetically. The order is deliberate: the error-tier alerts (broken promises) always show up first, no matter what, because they’re the most severe kind of narrative problem Desktop can detect. Warning-tier alerts (orphan plants and contradictions) come next, in alphabetical order by book. Info-tier alerts (when the ProseGuard slot is wired up) come last.
| Severity | Color | Alert types |
|---|---|---|
| Error | Red | Broken promises |
| Warning | Amber | Orphan plants, lore contradictions |
| Info | Blue | Future ProseGuard flags |
The link on every alert
Section titled “The link on every alert”Every alert includes a “Go to source” link. Clicking it takes you directly to the module that owns the issue, with the specific entity pre-selected. Broken promise alerts deep-link into Plot Studio with the plotline expanded and the promise highlighted. Orphan plants work the same way. Lore contradiction alerts deep-link into the Lorekeeper panel with the contradiction selected.
The point of the deep link is friction removal. If an alert is going to be useful, the path from seeing the problem to fixing the problem has to be one click. Three clicks is already too many — by the third click, the author has lost the thread of why they were doing this in the first place and clicked into a Legendry entry that had nothing to do with the alert.
No manual dismiss
Section titled “No manual dismiss”Same policy as the Attention Queue: you can’t dismiss an alert manually. The only way to clear one is to fix the source.
This is non-negotiable for the same reason. The failure mode of a dismissable alert is exactly the thing alerts exist to prevent — you see a broken promise, you dismiss it because you don’t want to deal with it right now, and then you forget the dismiss ever happened. Six months later, the promise is still broken, and because it’s dismissed, Desktop never reminds you. By the time the beta reader catches it, there’s no easy fix.
Fix the source. Mark the promise as fulfilled. Pay off the plant. Resolve the contradiction. The alert clears itself.
How alerts are stored
Section titled “How alerts are stored”Alerts aren’t a separate feature. They’re a view over data that already lives in other modules. Broken promises are status = 'broken' rows in the Plot Studio’s promises table. Orphan plants are status = 'orphaned' rows in the plants table. Lore contradictions are unresolved rows from the Lorekeeper’s contradiction-detection output.
Desktop queries those three tables on every load, filters to only the ones that should show up as alerts, and renders them in severity order. There’s no alert inbox. There’s no alert archive. When you fix a broken promise, the promise row’s status changes to fulfilled and the alert stops appearing — not because anything cleared it, but because the query it came from no longer matches.
What alerts are not
Section titled “What alerts are not”Alerts are not notifications. There’s no popup, no sound, no toast on save. If you fix a promise in Plot Studio, Desktop doesn’t show a “1 alert cleared” confirmation. The banner just updates silently the next time Desktop refreshes. This is intentional — Ishvana is a desktop app, and desktop apps confirm via direct UI state changes, not popups for every event.
Alerts are not a task list either. You can’t reorder them manually, you can’t annotate them, you can’t add your own alerts. If you need to track a self-imposed problem that Desktop’s alert system doesn’t know about, use Quick Notes.