npm - @telepath-computer/television - Versions diffs - 0.1.83 → 0.1.85 - Mend

@telepath-computer/television 0.1.83 → 0.1.85

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (15) hide show

package/dist/cli.cjs +83 -109
package/dist/skills/{television/artifact-types/calendar.md → artifact-calendar/SKILL.md} +20 -12
package/dist/skills/artifact-calendar/calendar.css +1 -0
package/dist/skills/artifact-calendar/calendar.js +716 -0
package/dist/skills/{television/html-house-style.md → artifact-calendar/house-style.md} +7 -7
package/dist/skills/{television/artifact-types/table.md → artifact-table/SKILL.md} +4 -1
package/dist/skills/artifact-table/house-style.md +67 -0
package/dist/skills/television/SKILL.md +428 -12
package/dist/web/assets/index-D3-COwxd.js +522 -0
package/dist/web/index.html +1 -1
package/package.json +1 -1
package/dist/skills/television/.skill-manifest.json +0 -29
package/dist/skills/television/artifact-workflow.md +0 -285
package/dist/skills/television/cli-capabilities.md +0 -145
package/dist/web/assets/index-BoxpwxlP.js +0 -522

package/dist/web/index.html CHANGED Viewed

@@ -4,7 +4,7 @@
     <meta charset="UTF-8" />
     <meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no" />
     <title>Television</title>
-    <script type="module" crossorigin src="./assets/index-BoxpwxlP.js"></script>
+    <script type="module" crossorigin src="./assets/index-D3-COwxd.js"></script>
     <link rel="stylesheet" crossorigin href="./assets/index-DfsusTzY.css">
   </head>
   <body></body>

package/package.json CHANGED Viewed

@@ -1,6 +1,6 @@
 {
   "name": "@telepath-computer/television",
-  "version": "0.1.83",
+  "version": "0.1.85",
   "type": "module",
   "main": "dist/cli.cjs",
   "bin": {

package/dist/skills/television/.skill-manifest.json DELETED Viewed

@@ -1,29 +0,0 @@
-{
-  "version": "0.1.10",
-  "files": [
-    {
-      "path": "SKILL.md",
-      "description": "Mental model, when to use Television vs chat, and routing to companion docs. Always read first."
-    },
-    {
-      "path": "cli-capabilities.md",
-      "description": "The `tv` CLI command surface plus the complete focus story — model, required decisions, theory of mind, phrase cues, screen placement, and the `--no-focus` communication rule."
-    },
-    {
-      "path": "artifact-workflow.md",
-      "description": "Artifact lifecycle work — markdown vs HTML, prescriptive recipes for create/update/modify/abandon/external/url, internal bundle structure and validation, in-flight narration style, and the quality bar."
-    },
-    {
-      "path": "html-house-style.md",
-      "description": "House style and conventions for authoring HTML artifacts that render inside Television."
-    },
-    {
-      "path": "artifact-types/calendar.md",
-      "description": "Authoring conventions for the calendar artifact kind."
-    },
-    {
-      "path": "artifact-types/table.md",
-      "description": "Authoring conventions for the record-table artifact kind: dense, Airtable-style tables of records."
-    }
-  ]
-}

package/dist/skills/television/artifact-workflow.md DELETED Viewed

@@ -1,285 +0,0 @@
----
-description: Artifact lifecycle work — markdown vs HTML, prescriptive recipes for create/update/modify/abandon/external/url, internal bundle structure and validation, in-flight narration style, and the quality bar.
----
-# Artifact workflow
-Read this document for Television artifact lifecycle work — creating, updating, committing, abandoning, attaching, detaching, deleting.
-The artifact-vs-chat decision and the mental model live in `SKILL.md`. The CLI command surface, focus decisions, and screen-placement guidance live in `cli-capabilities.md`. This doc covers everything else: which type to use, the staged lifecycle for internal artifacts, what each bundle file contains, validation rules, the quality bar, and the prescriptive recipes.
-If you are authoring an HTML artifact, also read `html-house-style.md` and check `artifact-types/` for any matching kind-specific doc.
-## Markdown or HTML
-Once you have decided to make an artifact, choose the type:
-- **markdown** when the result is primarily textual and benefits from simple structured reading. Headings, lists, code blocks, links. Most research summaries, comparisons, and write-ups.
-- **HTML** when richer layout, stronger visual hierarchy, or more custom presentation will make the result substantially better. Dashboards, multi-column layouts, custom-styled cards, simple interactive widgets, anything where typographic prose is not the dominant mode.
-Default to markdown. HTML is more work to author, more work to maintain, and only pays off when the visual structure is doing real communicative work.
-## Authoring quality
-This applies to every artifact you author or maintain — internal, external, or URL.
-Build artifacts that are durable, truthful, and maintainable by later agents.
-Required standards:
-- be faithful to source material
-- do not invent missing facts to make the artifact look complete
-- do not silently truncate a dataset and pretend it is comprehensive
-- prefer truth over completeness when those goals conflict
-- make limitations, sampling, gaps, and freshness visible when they matter
-- keep the rendering aligned with the reasoning captured in the bundle files (for internal artifacts)
-- keep the artifact maintainable by a future agent reading only the bundle (for internal artifacts)
-Anti-patterns to avoid:
-- cursory or low-effort data collection
-- fake completeness — padding to look thorough
-- brittle one-off hacks that a later agent cannot reproduce
-- hidden dependencies that are not documented in the bundle
-- unnecessary layout or styling churn during a simple data refresh
-## Before creating artifacts
-Before starting artifact-creation tool work, briefly tell the user what you are about to make. Artifact creation can take noticeable time, and the user may not otherwise be able to tell what is happening during the agent loop.
-Also work expediently. Do not skip lifecycle or validation steps, but avoid unnecessary extra steps when building the artifact. There is real user wait time while artifact creation is in progress.
-## In-flight narration style
-While a multi-step artifact workflow is running, narrate concisely so the user knows you are still working. Frame updates in their world and goals, not in CLI mechanics or workflow jargon.
-Required style:
-- verbalize key actions and decisions as they happen
-- keep updates short — a sentence per beat, not a paragraph
-- prefer the user's framing over Television's internal machinery
-- do not write reports, retrospective summaries, or chatty explanations while work is in progress
-- do not use bullet lists unless the user explicitly asks for one
-- optimize for speed and token efficiency
-Good examples:
-- "Starting the artifact now."
-- "Reviewing the draft and source material."
-- "Updating the HTML and moving through the artifact creation flow."
-- "The artifact did not pass validation; fixing the draft notes and retrying."
-- "Finalizing the artifact now."
-- "Done."
-Avoid:
-- multi-paragraph progress reports
-- long retrospective narration during execution
-- verbose bullet lists for routine workflow steps
-- workflow jargon ("calling commit-pending-artifact", "validator rejected memory.md") unless the user is debugging Television itself
-## Internal bundle structure
-Internal artifacts are Television-managed bundles. Every internal artifact bundle contains:
-- `artifact.md`
-- `data.json`
-- `memory.md`
-- `public/index.md` or `public/index.html`
-Fresh pending bundles are intentionally minimal. Do not treat the scaffold as meaningfully authored content — the structure below describes what each file must contain before commit.
-External artifacts and URL artifacts have no bundle and no pending lifecycle.
-### `artifact.md`
-`artifact.md` is the contract for the artifact. It explains what the artifact is for, what material it is based on, how it should render, and how later agents should maintain it.
-Before commit, `artifact.md` must be non-empty and contain all of these exact headings:
-```md
-## User intent
-## Purpose
-## Data shape
-## Data sources
-## Rendering
-## Update workflow
-## Non-goals
-```
-Section guidance:
-- `## User intent` — faithfully preserve what the user actually wants, including requests, constraints, corrections, complaints, and feedback when those matter. Use direct quotes when helpful.
-- `## Purpose` — what the artifact is trying to achieve.
-- `## Data shape` — the conceptual structure you used while authoring. For markdown artifacts this is often just `{}`.
-- `## Data sources` — where the underlying facts came from and how they were obtained.
-- `## Rendering` — how the public entry file should present the result.
-- `## Update workflow` — how a future agent should refresh or modify it correctly.
-- `## Non-goals` — important exclusions, especially when it would be easy to overbuild (e.g., "this is a static report, not a live dashboard").
-### `data.json`
-`data.json` is a thinking artifact, not a runtime payload.
-Use it to clarify authoring structure when that helps you think, not to create an application state layer.
-Hard rules:
-- do not treat `data.json` as live runtime state
-- do not build HTML/JS that depends on `data.json` as an application data source
-- do not turn Television artifacts into runtime data-backed apps through `data.json`
-- artifacts are static markdown or static HTML documents; HTML artifacts may include presentation-oriented JavaScript and assets under `public/`, but JS must not be driven by `data.json` as application state
-For markdown artifacts, prefer to leave `data.json` as exactly:
-```json
-{}
-```
-For HTML artifacts, use `data.json` only when it materially helps your authoring process.
-Validation requires that `data.json` exist and contain valid JSON.
-### `memory.md`
-`memory.md` is for maintenance-oriented notes to future agents.
-Record decisions, limitations, source-retrieval notes, problems encountered, what changed, and anything that should be watched during future edits.
-Required validation anchors:
-- `memory.md` must contain `## Activity Log`
-- it must contain at least one UTC timestamp in exact `YYYY-MM-DDTHH:MM:SSZ` format
-- at least one timestamp must be fresh enough for commit validation (recent enough to prove this commit is current)
-### Public entry file
-This is what Television actually renders.
-- markdown artifacts use `public/index.md`
-- HTML artifacts use `public/index.html`
-- the entry file must match the artifact type
-- the entry file must be non-empty before commit
-- HTML artifacts may include additional public assets under `public/`; keep paths relative
-For HTML artifacts, also read `html-house-style.md`.
-## Workflows
-These recipes are prescriptive on purpose. The lifecycle steps and their order matter — `commit-pending-artifact` will refuse a bundle that has not satisfied the validation anchors above.
-### Create a new internal artifact
-1. Confirm internal is the right kind for this result (the result should be Television-owned and maintainable by future agents).
-2. Tell the user what you are about to make before starting tool work.
-3. Stage the pending bundle:
-   ```bash
-   tv create-internal-artifact --screen "<screen-id>" --type text/markdown --title "Artifact title" --focus-artifact
-   ```
-   Or, for HTML:
-   ```bash
-   tv create-internal-artifact --screen "<screen-id>" --type text/html --title "Artifact title" --no-focus
-   ```
-   `--screen` is required so the artifact has immediate screen membership. `--focus-artifact` or `--no-focus` is required so focus is an explicit choice. (See `cli-capabilities.md` for how to make that choice.)
-4. Read the returned pending path. Edit files there.
-5. Write `## User intent` in `artifact.md` **first**, before authoring anything else. Capture the user's language faithfully — direct quotes when helpful, close paraphrase when clearer. The rest of the bundle should serve that intent, so writing it first anchors the work and keeps you from retrofitting intent from memory after the fact.
-6. Fill out the remaining required `artifact.md` headings: `## Purpose`, `## Data shape`, `## Data sources`, `## Rendering`, `## Update workflow`, `## Non-goals`.
-7. Use `data.json` only as an authoring aid — not as runtime state. For markdown artifacts, leave it as `{}` unless there is a strong authoring reason not to.
-8. Render `public/index.md` or `public/index.html`. The entry file must match the artifact type and must be non-empty.
-9. Append a current UTC-timestamped entry under `## Activity Log` in `memory.md` (format: `YYYY-MM-DDTHH:MM:SSZ`). At least one timestamp must be fresh enough to satisfy commit validation.
-10. Commit:
-    ```bash
-    tv commit-pending-artifact --id "<artifact-id>"
-    ```
-    If the validator rejects the commit, read the directive, fix the bundle, and retry. Do not bypass validation by editing committed state directly.
-### Update an internal artifact with fresh data
-1. Stage the edit:
-   ```bash
-   tv edit-internal-artifact --id "<artifact-id>"
-   ```
-2. Read `artifact.md`, `data.json`, and `memory.md` before changing anything. They tell you what the artifact is, what shape it expects, and what prior agents decided.
-3. Refresh the underlying facts or source material.
-4. Update `data.json` only if it improves the authoring model. For markdown artifacts, prefer to keep it as `{}`.
-5. Make the minimum rendering changes needed to keep the artifact correct. Avoid layout or styling churn during a data-only refresh — that breaks the user's mental model of "same artifact, fresher data."
-6. Append a current UTC-timestamped entry to `## Activity Log` in `memory.md` describing what changed.
-7. Commit:
-   ```bash
-   tv commit-pending-artifact --id "<artifact-id>"
-   ```
-### Modify an internal artifact from user feedback
-1. Stage the edit (`tv edit-internal-artifact --id "<artifact-id>"`).
-2. Read `artifact.md`, `data.json`, and `memory.md`.
-3. Update `## User intent` in `artifact.md` so it remains a faithful record of what the user actually wants now. Preserve the user's new language as direct quotes or close paraphrases. Old intent that no longer reflects the current ask should be revised, not just appended to.
-4. Update `## Non-goals` if the user has ruled something out.
-5. Adjust `data.json` only if the authoring model changed.
-6. Adjust `public/index.md` or `public/index.html` as narrowly as the change requires.
-7. Append an `## Activity Log` entry capturing the request, the decision, and the resulting change with a current timestamp.
-8. Commit.
-### Abandon pending work
-If staged work should be discarded rather than committed:
-```bash
-tv abandon-pending-artifact --id "<artifact-id>"
-```
-For a pending create, the artifact never becomes live. For a pending edit, the previously committed version is kept unchanged.
-### Create an external artifact
-External artifacts point at a file that already exists on disk. Television displays it and watches for changes, but does not own it — there is no bundle and no pending lifecycle.
-```bash
-tv create-external-artifact --screen "<screen-id>" --type text/markdown --title "Artifact title" --path /absolute/path/to/file.md --focus-artifact
-```
-Or:
-```bash
-tv create-external-artifact --screen "<screen-id>" --type text/html --title "Artifact title" --path /absolute/path/to/file.html --no-focus
-```
-Rules:
-- `--path` must be absolute
-- the file must already exist and be readable
-- the extension must match `--type`
-- there is no pending create / pending edit / commit / abandon flow
-- `tv delete-artifact` only forgets the pointer; the underlying file is never deleted
-### Create a URL artifact
-URL artifacts embed a live `http(s)://` page. They commit immediately and have no pending lifecycle.
-```bash
-tv create-url-artifact --screen "<screen-id>" --title "Artifact title" --url https://example.com --focus-artifact
-```
-Or:
-```bash
-tv create-url-artifact --screen "<screen-id>" --title "Artifact title" --url https://example.com --no-focus
-```
-Rules:
-- `--url` must be `http://` or `https://`
-- the type is always `text/html` — do not pass `--type`
-- in the desktop app the page renders in a sandboxed `<webview>`; in the browser it renders in an `<iframe>`
-- some sites block embedding (X-Frame-Options, CSP); if the page may be one of those, prefer an internal artifact that links to the page

package/dist/skills/television/cli-capabilities.md DELETED Viewed

@@ -1,145 +0,0 @@
----
-description: The `tv` CLI command surface plus the complete focus story — model, required decisions, theory of mind, phrase cues, screen placement, and the `--no-focus` communication rule.
----
-# TV CLI capabilities
-Use this document when you need to reason about what the `tv` CLI can do, which command family fits the user's request, and how focus and screen placement should be decided.
-## Agent recovery surfaces
-The Television skill is the primary agent guidance surface.
-If the skill is installed, load/read `television` and then use the companion docs.
-If the skill is not installed, use:
-```bash
-tv skills show
-```
-That lists the bundled Television skill files, prints the skill root, and tells you how to read one file directly.
-To read a specific bundled skill file directly:
-```bash
-tv skills show <relative-path>
-```
-`tv help` is normal CLI help plus routing pointers. It is not the old mega-skill blob anymore.
-## Command surface
-The CLI is the source of truth for command syntax and per-command behavior. Run:
-```bash
-tv help
-```
-for the full command list. For details, flags, and behavioral nuance for a single command, run:
-```bash
-tv help <command>
-```
-The help text is intentionally written to surface non-obvious semantics — idempotency, cascading effects, transient vs persistent state changes, JSON vs plain-text output, and so on. Read it before choosing a command, especially when two commands look superficially similar (detach vs delete, focus-screen vs focus-artifact, attach vs create).
-Commands group into four intents:
-- **Screen commands** — create, inspect, remove, or switch screens (`create-screen`, `list-screens`, `get-screen`, `remove-screen`, `focus-screen`, `focus-status`).
-- **Artifact creation and lifecycle commands** — create or maintain artifact content (`create-internal-artifact`, `edit-internal-artifact`, `commit-pending-artifact`, `abandon-pending-artifact`, `create-external-artifact`, `create-url-artifact`).
-- **Artifact membership and removal commands** — place, unplace, inspect, retitle, or remove an existing artifact (`attach-artifact`, `detach-artifact`, `delete-artifact`, `get-artifact`, `list-artifacts`, `update-artifact`, `focus-artifact`).
-- **Server and environment commands** — operate on the Television server itself (`serve`, `status`, `stop`, `storage-path`).
-When the CLI rejects a command, follow the directive it prints rather than guessing flags.
-## Read vs mutate
-Read commands print JSON. Mutation and workflow commands print plain text.
-Use read commands when you need authoritative state for planning or verification. Use mutation commands when you are intentionally changing Television state.
-## Focus model
-Television separates state changes from focus. Choosing where an artifact lives is one decision; choosing whether the user's attention moves there is a separate one.
-- **screen focus** is persistent: which screen the user is currently looking at
-- **artifact focus** is transient: clients may switch screens first, then scroll and highlight the artifact
-There is a persisted focused screen.
-There is not a persisted focused artifact.
-Important consequence: creating or attaching something does not by itself answer whether the user should be taken to it now.
-## Required explicit focus decisions
-Create and attach commands require an explicit focus decision.
-- `tv create-screen` requires exactly one of `--focus-screen` or `--no-focus`
-- `tv create-internal-artifact`, `tv create-external-artifact`, `tv create-url-artifact`, and `tv attach-artifact` require exactly one of `--focus-artifact` or `--no-focus`
-If you omit that decision, the CLI rejects the command. Dedicated `focus-screen` and `focus-artifact` commands can also move attention later as separate steps.
-## Choosing the focus directive
-Think about the user's current attention stream before deciding. Use theory of mind: what are they probably attending to right now? Do they expect an immediate reveal, or would moving their view feel jarring? What will they likely want to do next?
-Rules of thumb:
-- **focus now** when seeing the result immediately is part of successfully answering the request
-- **`--no-focus`** when the user is likely to want the result available without breaking their current flow, or when the work should run in the background
-- **direct `focus-screen` / `focus-artifact` commands** when placement and attention movement should happen as separate steps
-If you used `--no-focus`, explicitly tell the user what you did and where it went. Otherwise the Television display may not visibly change and the user may not know whether anything happened. Same applies if you placed something on a non-current screen without focusing it: name the screen. If you did move focus, say so, because that affects what the user will see next.
-## Listening for focus intent in the user's language
-The user's phrasing is a strong cue — not a deterministic rule, but a real signal worth listening for.
-Phrases that usually indicate the user wants attention moved (use a focus flag, or a direct `focus-screen` / `focus-artifact` command):
-- "show me", "show me that", "let me see it", "let me review it"
-- "switch to", "change to", "go to", "take me there", "open it"
-- "put it on screen", "put it on my screen", "bring it up"
-- references to the **active**, **current**, **showing**, or **visible** screen or artifact
-Phrases that usually indicate the user wants the work to happen without disturbing their current view (use `--no-focus`):
-- "in the background", "while I'm doing X", "while I work on Y go and do Z"
-- "set this up", "prepare it", "wire it in", "get it ready"
-- "don't interrupt me", "leave my screen alone", "don't switch"
-These are illustrative, not exhaustive. When the language is ambiguous or unusual, reason about the user's attention stream instead of pattern-matching keywords.
-## Screen placement
-Artifact creation commands require `--screen` because new artifacts need immediate screen membership. Use `attach-artifact` and `detach-artifact` when the artifact already exists and you are changing where it appears.
-Think carefully about whether the user means:
-- create something new on a screen
-- place an existing artifact on a screen
-- stop showing an artifact on a screen
-- globally delete an artifact everywhere
-Those are different operations with different consequences. The per-command help text spells out which is which.
-### Choosing the right screen
-When deciding where an artifact should go:
-- If the current screen is the right place and the user should see the result immediately, create or attach the artifact there with `--focus-artifact`.
-- If the current screen is the right place but the work should appear without interrupting their reading flow, create or attach with `--no-focus`.
-- If the work belongs on a different existing screen, place it there. Then decide whether to focus or merely tell the user where it is.
-- Sometimes a new screen is the right call.
-### When to create a new screen
-Reach for `tv create-screen` when:
-- the request is meaningfully separate from the current screen's purpose
-- the result should become its own durable workspace the user can return to
-- mixing it into the current screen would make the user's mental model worse (e.g., a research dossier vs a live dashboard, or two unrelated topics that should not share a strip)
-Default to placing things on an existing screen unless one of those conditions is true. Spawning a new screen for every request fragments the user's workspace; spawning none ever forces unrelated content together.