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
+3Lines changed: 3 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -94,11 +94,14 @@ 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 open by default for normal editor entry; `Raw` remains available as the canonical TPS source view for technical editing.
97
98
- 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.
99
+
- Technical TPS objects such as headers, metadata chips, edit points, cuts, pauses, breath marks, pronunciation guides, and timing controls must be visually distinguished from spoken script text in both `Raw` and styled `Editor`, and should offer object-like hover/edit affordances instead of looking like ordinary words.
98
100
- 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
101
- 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
102
- 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.
101
103
- 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.
104
+
- TPS cue visual language must be shared across Raw editor, styled `Editor`, and Teleprompter reader surfaces; colors, typography, cue marks, and motion metaphors should come from one canonical style contract so the same TPS element reads the same way everywhere.
102
105
- 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.
103
106
- 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.
104
107
- TPS cue rendering work must start from an explicit design note that maps each supported TPS style to its reader/editor visual treatment, animation, and test expectation before implementation, so the product does not grow one-off cue styling.
0 commit comments