You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: AGENTS.md
+4Lines changed: 4 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -94,6 +94,10 @@ Rule format:
94
94
- TPS authoring completeness must be checked against the upstream `managedcode/TPS` README, not only the currently shipped editor menus, so new editor support stays aligned with the full spec for emotions, delivery, pauses, speed, pronunciation, and related cues.
95
95
- Editor TPS command surfaces must expose the full currently supported TPS authoring set consistently across top toolbar menus, floating-toolbar menus, and Monaco assistance; do not ship partial or differently grouped command taxonomies between those surfaces.
96
96
- The editor must support multiple authoring views: `Raw` is the canonical TPS source editor with tags, and `Editor` is the WYSIWYG-style styled-text editor that hides raw Markdown/TPS syntax while preserving text styling for non-technical authors. Do not label the styled authoring tab as `Rendered`; it is still an editor, and card or storyboard concepts must be separate modes when explicitly requested.
97
+
- The styled `Editor` authoring view must be a full Monaco-backed editing surface with cursor, selection, keyboard editing, find behavior, and undo/redo parity with `Raw`; rendered styling should be applied through Monaco decorations or equivalent editor-native layers, not by replacing the editor with a static preview or separate non-editable DOM.
98
+
- Styled `Editor` TPS hover tooltips must be compact, readable, and viewport-safe; they should explain what the hovered cue/header element means and how it affects authoring without giant clipped Monaco popovers.
99
+
- Styled `Editor` header metadata must not dominate the authoring surface or expose vague labels such as `Header metadata`; speaker, WPM, emotion, timing, and archetype parts need clear semantic labels and should stay visually subordinate to the actual script text.
100
+
- Styled `Editor` Monaco performance must avoid redundant hidden overlay rendering and unnecessary full-document decoration work while typing; optimize the editor-native decoration path before adding more DOM layers or broad scans.
97
101
- TPS cue semantics must be visually represented across both the editor and live reader surfaces: emotions, delivery, voice, pace, energy, pauses or breath marks, pronunciation, phonetics, stress, staccato, legato, emphasis, highlight, aside, rhetorical, building, sarcasm, loud, soft, whisper, and related cues need visible affordances that help the user read intent without inspecting raw TPS tags.
98
102
- TPS word and emotion treatments should use tasteful word-level CSS effects such as gradients, shadows, underline textures, and constrained animation when they make the cue more legible and interesting; do not limit cue rendering to flat color changes, but never let effects reduce readability or cause word overlap.
99
103
- TPS emotion cue colors must be meaningfully distinguishable from each other and should be grounded in color/emotion theory where possible; do not ship a set of near-identical pastel tints that users cannot tell apart while reading.
0 commit comments