diff --git a/.claude/skills/t27f/SKILL.md b/.claude/skills/t27f/SKILL.md index 4e149ae66d..b7f5aa7a63 100644 --- a/.claude/skills/t27f/SKILL.md +++ b/.claude/skills/t27f/SKILL.md @@ -1,10 +1,10 @@ --- id: t27f -name: T27F Topic Engine -description: Turn any topic or client brief into three lenses, a 27-lesson map, one relevant Bee task and a verified artifact, with gaps shown, evidence gates and human approval for anything that leaves the machine. Use when the user says "t27f", "explain this topic in 27 steps", "turn this brief into a plan", or gives a client brief (villa, car, campaign, product) or a research/engineering topic. +name: T27F Visual Spec +description: T27F is the visual spec of a .t27 file -- one spec, one synchronized model, many views (source, architecture, data flow, dependencies, tests and benchmarks), every node labelled exact, derived, suggested or unknown and linked to its source span (gHashTag/trinity#1648, RFC gHashTag/trinity#1649). Use when the user says "t27f", "visual spec", "show / visualize / draw this spec", or opens a .t27 file to see its structure. Also runs the topic-map application built on T27F (gHashTag/trinity#1677) when the user gives a topic or a client brief. --- -# T27F Topic Engine +# T27F Visual Spec > **Only t27: everything is written in `.t27`.** (Owner hard rule 2026-10-05; budget #7371; restated in every skill per #7588.) @@ -15,13 +15,82 @@ description: Turn any topic or client brief into three lenses, a 27-lesson map, > - What gen cannot express yet is a compiler defect. File it on #5980 with a minimal `.t27` repro instead of writing the code by hand. > - This rule overrides any step below that says to write a script or code in another language. The full text is in `AGENTS.md`, "Only t27". -Phase 1 vertical slice of gHashTag/trinity#1677 (parent gHashTag/trinity#1648). - -**The rules live in one place: `specs/t27f/topic_engine.t27`.** This skill is the order of +## What T27F is + +**This section is the one home of the definition.** `CLAUDE.md`, `specs/OWNERS.md`, the skill card +`specs/skills/t27-t27f.t27` and the spec headers point here; they do not restate it. + +T27F is the **visual spec of `.t27`**: every t27 specification has a first-class visual form, an +interactive, inspectable diagram built from reusable widgets. Sources: epic gHashTag/trinity#1648 +("native generative UI and visual application engine") and RFC gHashTag/trinity#1649 ("specs as +executable visual diagrams"). + +- **One spec -> one synchronized source model -> many views**: source, architecture diagram, data + flow, dependency graph, tests/benchmarks, docs. Every view is derived from the real spec + (AST/IR plus metadata), never a hand-drawn picture that can drift from the code. +- **Graph IR**: versioned, typed nodes (module, function, step, input/output/parameter/constant, + type/numeric format, branch/loop, operator, dependency, test/invariant/oracle, benchmark/hardware, + paper/dataset, opaque region) and typed edges (data flow, control flow, calls/depends on, + produces/consumes, constrains, tested by, measured by, implemented by, cited by). The full lists + are in #1649. +- **Every node carries one inference label**: `exact` (present in the AST/IR), `derived` (safe from + symbol and type resolution), `suggested` (a model's explanation, visibly marked, linked to source + ranges) or `unknown`. A model's guess is never drawn as a verified property of the program. +- **Bidirectional source mapping**: select a node, see its source span; select a line, see its + node. Generation is deterministic for a fixed source and toolchain, and two revisions produce a + graph diff. +- **Read-only viewer first.** Editing comes after the schema survives two structurally different + specs. GF16 (`specs/numeric/gf16.t27`) is a *candidate* pilot pending the comparison in #1651. +- **The pipeline (#1648)**: intent -> versioned system description -> domain model and computation + -> renderer-neutral UI plan (trusted widget ids, bindings, layout, actions, theme, a11y, + provenance) -> T27F renderer -> verification loop. A model never ships code to the renderer: no + eval, no generated JS, only widgets from an allowlist. +- **In the map** (#1648 comments, 2026-10-16): zooming into a honeycomb cell opens that cell's spec + as a navigable program, linked to source, tests, issues and real task status; each cell is both a + spec and a learning entry point. + +**What T27F is not:** it is not the topic-to-value engine. gHashTag/trinity#1677 (topic or client +brief -> 27-lesson map -> Bee -> verified artifact) is an *application* built on T27F, and so are +the reels. Describing T27F as #1677 is the error this section exists to stop (owner correction, +2026-10-17). + +## What exists and what does not + +| Layer | Where | State | +|---|---|---| +| Spec -> graph IR (the core) | none yet | **missing**. AST/IR audit is trinity#1650, pilot choice #1651. `t27c` has no graph export | +| UI plan IR + trusted widget catalog | `specs/t27f/ui_plan.t27` (t27#9962) | spec with tests; no renderer draws a plan yet | +| Honeycomb focus+context geometry | `specs/t27f/reel.t27` | spec; stills drawn by the MCP tool `t27f_view` | +| Renderer in the Trinity UI | gHashTag/trinity | **missing**; no T27F widget is live | +| Application: topic map (#1677) | `specs/t27f/topic_engine.t27`, `topic_reel.t27` | spec; procedure below | +| Application: reels and deck | `specs/t27f/reel.t27`, `deck.t27`, `reel_*.t27` | spec; two reels | +| Related | trinity#1647 dashboards, #1652 MVP research, #1653 three skills, #1655 evolution runtime | open | + +When asked "how is T27F going", report against the core rows first. Progress on the applications +is not progress on the core. + +## Show a spec (the core, done by hand until the graph IR exists) + +1. Load the spec: `mcp__t27__t27_spec` with `path` and `source: true`, or the file from a + gHashTag/t27 checkout. Say which one you used. +2. List nodes and edges from the source only: module, imports (`use`), constants, functions, + `test` / `invariant` / `bench` blocks, calls between them, which tests exercise which function. + Give every node and edge its line span and its label (`exact` / `derived` / `suggested` / + `unknown`). +3. Show it as a table (node, kind, span, label) and, if useful, a diagram whose every arrow is a + row of that table. Nothing is drawn that the table does not back. +4. Say plainly that this is a manual reading, not T27F output: deterministic generation needs the + graph-IR spec, which does not exist yet. Name that gap rather than hide it. + +## Application: topic map (gHashTag/trinity#1677) + +Use this part when the user gives a topic or a client brief, not a spec. + +**Its rules live in one place: `specs/t27f/topic_engine.t27`.** This section is the order of operations around it. It never restates a constant, a vocabulary or a gate; it reads them. If this text and the spec disagree, the spec wins and this text is the bug. -## 0. Load the engine +### 0. Load the engine Read the spec through the t27 MCP server, which is already installed in Claude Code: @@ -38,7 +107,7 @@ functions `intake_verdict`, `map_verdict`, `initial_status`, `ground`, `route`, Everything in `DETERMINISTIC_STEPS` is decided by those functions, never by your judgement. You write only what `LLM_WRITES` names. -## 1. Intake +### 1. Intake Ask for, or take from the message: the topic or brief, and its sources (links, files, notes). Apply `intake_verdict(has_topic, source_count)`: @@ -47,19 +116,19 @@ Apply `intake_verdict(has_topic, source_count)`: - `INTAKE_NO_SOURCES`: continue, but every lesson starts as a GAP. Say so up front. - `INTAKE_OK`: continue. -## 2. Route +### 2. Route Count the brief's hits against each `*_WORDS` list exactly as `KEYWORD_MATCH` says. Show the four counts and the words that hit, then apply `route(content, engineering, research, sales)`. Name the domain and the Bee list it allows. Do not override the result; if it looks wrong, the vocabulary in the spec is what needs a PR. -## 3. Three lenses +### 3. Three lenses Write one short paragraph per lens, answering that lens's question from `LENS_QUESTIONS`, using only the sources. A claim with no source is not written; it becomes a gap. -## 4. The 27-lesson map +### 4. The 27-lesson map Print a table of 27 rows, lens-major (`step_lens`, `step_stage`): step, lens, stage, lesson title, source, status. @@ -72,7 +141,7 @@ source, status. else. Never invent filler to make the map look complete. - Count grounded lessons per lens and report `map_verdict(...)`. -## 5. One Bee task +### 5. One Bee task Apply `bee_target(open_lessons)`. `TARGET_OPEN_LESSON`: take the first OPEN lesson. `TARGET_FIRST_GAP` (nothing is OPEN, as when intake was `INTAKE_NO_SOURCES`): take the first GAP, the @@ -87,7 +156,7 @@ domain's Bee list and write one task for it: In this phase the Bee is you, in this session, or a delegated Agent if the user asks for it. Never start more than `MAX_ACTIVE_BEES`, and never one per lesson. -## 6. Draft, then verify +### 6. Draft, then verify Produce the artifact as a DRAFT and label it as one. Collect the evidence (a source link, a passing test, a review, the client's approval). Apply `verify(DRAFT, stage, domain, evidence)`. @@ -97,7 +166,7 @@ test, a review, the client's approval). Apply `verify(DRAFT, stage, domain, evid points as money, tokens, payouts or value. - `opens_next(DRAFT)` is true, so the learner may move on while the draft waits for evidence. -## 7. Approval gate +### 7. Approval gate Before any action, check `needs_human_approval(action)` and `action_allowed(status, action, approved)`. @@ -108,13 +177,13 @@ approved)`. DRAFT, because a client approval is the only evidence that verifies a sales or content DELIVER lesson; the draft stays a DRAFT (`after_action`) until that approval comes back. -## 8. Keep the three layers apart +### 8. Keep the three layers apart Keep drafts, verified results and published items under separate headings (`layer_of`). If the journey is saved, save it as a `.t27` data module, not JSON. Saving follows the user's instruction. ## What this skill does not claim -No runtime dispatches Bees from the spec yet, and nothing publishes on its own. Those are later -phases of gHashTag/trinity#1677. If a step needs one of them, say that it is missing; do not -simulate it. +No tool turns a spec into a graph IR yet, no renderer draws a T27F view in the Trinity UI, no +runtime dispatches Bees from a spec, and nothing publishes on its own. If a step needs one of +them, say that it is missing; do not simulate it. diff --git a/CLAUDE.md b/CLAUDE.md index ef3c5be189..f2b2d7ad83 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -179,6 +179,17 @@ See [`docs/T27-CONSTITUTION.md`](docs/T27-CONSTITUTION.md#2--invariant-laws-neve **Repository:** Trinity S³AI — **t27** (spec-first ternary / TRI-27). **φ² + 1/φ² = 3 | TRINITY** +## T27F is the visual spec of `.t27` + +T27F means one thing: every `.t27` spec gets a visual form -- one spec, one synchronized model, +many views (source, architecture, data flow, dependencies, tests), every node labelled exact, +derived, suggested or unknown and linked to its source span (gHashTag/trinity#1648, RFC +gHashTag/trinity#1649). It is **not** the topic-to-value engine: gHashTag/trinity#1677 and the +reels are applications built on T27F. Owner correction, 2026-10-17. + +This is a pointer. The definition, and what exists versus what is still missing, live in one +place: `.claude/skills/t27f/SKILL.md`, section "What T27F is". + ## Own language first When this project publishes something about itself, it publishes in **this diff --git a/specs/OWNERS.md b/specs/OWNERS.md index 38bf812cc9..4dea6415ac 100644 --- a/specs/OWNERS.md +++ b/specs/OWNERS.md @@ -28,7 +28,7 @@ | `docs/` | **Z-Zeta** (with **T-Queen** for `chapters/queen.t27`) | The system documentation of `t27.ai/#/docs` as `.t27` specs (`docs/system.t27`, `KIND = "docs"`; `docs/chapters/.t27`, `KIND = "docs-chapter"`): chapter ids, sections, sources, the figure and table the site generates; English prose in `docs/system/.md`, Russian via `i18n/docs-ru.t27` | | `ui/` | **T-Queen** | The site's viewport contract as a `.t27` spec (`ui/viewport.t27`, `KIND = "viewport"`): tiers by CSS viewport width, panes per tier, the 44 px touch minimum, the six-size QA matrix and the Queen rail capacity read from `Queen.css`; the site (gHashTag/trinity) generates `viewport.generated.ts` / `.css` from a vendored copy and evaluates the spec's own test blocks; `ui/queen_evidence.t27` (`module ui_queen_evidence`): the evidence constants of the Queen's FFN and Ternary Check panel, from which the site generates `queenEvidence.generated.ts`; canonical here since S10, byte-identical to the copy the site carried alone | | `catalog/` | **T-Queen** | How the site's spec catalog and the Queen map find the repositories that write `.t27` (`catalog/discovery.t27`, `KIND = "discovery"`): the GitHub owners scanned, the exclusions, what makes a candidate qualify (a declaration in the compiler's AST, not a file extension) and the limits; the site (gHashTag/trinity) vendors a byte-identical copy and `scripts/discover-t27-worlds.mjs` reads it through the compiler wasm before touching GitHub | -| `t27f/` | **T-Queen** | The T27F topic-to-value engine of gHashTag/trinity#1677 (`t27f/topic_engine.t27`, module `T27fTopicEngine`): the 3 x 9 = 27 lesson shape, intake and gap rules, keyword routing to one domain, the Bee dispatch cap, the evidence and approval gates, and progression that is never money; driven by the Claude Code skill `.claude/skills/t27f/SKILL.md` through the t27 MCP server; `t27f/reel.t27` (module `T27fReel`): the video format of a topic map and the still views of a Claude Code answer -- honeycomb geometry, focus+context camera, scene catalog, per-target limits, gap styling, the posting gate and the channel per host; numbers only, a host draws them; `t27f/deck.t27` (module `T27fDeck`): the default look of a reel, every scene a presentation slide -- layouts per scene, regions, type sizes, glass card, palette kept off the status colours, contrast and card fades | +| `t27f/` | **T-Queen** | T27F, the visual spec of a .t27 file (gHashTag/trinity#1648, RFC #1649; definition in `.claude/skills/t27f/SKILL.md`): `t27f/ui_plan.t27` (module `t27f_ui_plan`): the renderer-neutral UI plan IR and the trusted widget catalog. Applications built on it: the topic-to-value map of gHashTag/trinity#1677 (`t27f/topic_engine.t27`, module `T27fTopicEngine`): the 3 x 9 = 27 lesson shape, intake and gap rules, keyword routing to one domain, the Bee dispatch cap, the evidence and approval gates, and progression that is never money; driven by the Claude Code skill `.claude/skills/t27f/SKILL.md` through the t27 MCP server; `t27f/reel.t27` (module `T27fReel`): the video format of a topic map and the still views of a Claude Code answer -- honeycomb geometry, focus+context camera, scene catalog, per-target limits, gap styling, the posting gate and the channel per host; numbers only, a host draws them; `t27f/deck.t27` (module `T27fDeck`): the default look of a reel, every scene a presentation slide -- layouts per scene, regions, type sizes, glass card, palette kept off the status colours, contrast and card fades | | `trinity/` | **T-Queen** + **A-Architect** | The project manifest of gHashTag/trinity as `.t27` specs (`trinity/project.t27`, `KIND = "project"`; `trinity/capabilities/.t27`, `KIND = "capability"`): the pinned consumer revision, profiles, dispositions and evidence tags, dialect and build counts, dependency pins and the work packages of gHashTag/trinity#988; each card names its owner, canonical spec, implementation and generated paths, build targets, acceptance command and evidence; `tools/trinity_manifest.py` derives the inventory from a clean pinned checkout and holds the cards to it; `trinity/compiler_matrix.t27` (`KIND = "compiler-matrix"`) names the pinned compiler, the backends, the stages and the features of the executable subset with their fixtures under `bootstrap/tests/fixtures/trinity_matrix/`, and `tools/trinity_compiler_matrix.py` measures them; `trinity/build_graph.t27` (`KIND = "build-graph"`) declares the consumer's toolchain, pins, profiles, generated-file boundaries and receipt policy, and `tools/trinity_build_receipt.py` derives the graph, writes the receipts and judges drift; the consumer vendors a byte-identical copy and generates its manifest from it (S12). Shared contracts stay in their own subtrees (`numeric/`, `vsa/`, `queen/`, `tools/`, `docs/`, `ui/`) and are cited, never copied | Each subtree with substantial churn should keep a local **`OWNERS.md`** (see below). diff --git a/specs/skills/t27-t27f.t27 b/specs/skills/t27-t27f.t27 index 48572342e3..c9fd5f1309 100644 --- a/specs/skills/t27-t27f.t27 +++ b/specs/skills/t27-t27f.t27 @@ -1,8 +1,10 @@ // SPDX-License-Identifier: Apache-2.0 ; specs/skills/t27-t27f.t27 -- skill t27/t27f ; Source of truth for the skill card on t27.ai (#/skills?skill=t27/t27f). -; The skill body lives in gHashTag/t27 at .claude/skills/t27f/SKILL.md; its rules live in -; specs/t27f/topic_engine.t27 (gHashTag/trinity#1677). +; The skill body lives in gHashTag/t27 at .claude/skills/t27f/SKILL.md. T27F is the visual spec of a +; .t27 file (gHashTag/trinity#1648, RFC gHashTag/trinity#1649); its UI plan IR is +; specs/t27f/ui_plan.t27. The topic-map application (gHashTag/trinity#1677) has its rules in +; specs/t27f/topic_engine.t27. ; The JSON the site serves is generated from this file by the real compiler; ; nothing below is parsed with a regex. ; phi^2 + 1/phi^2 = 3 | TRINITY @@ -11,15 +13,15 @@ module skill_t27_t27f; pub const KIND : str = "skill"; pub const ID : str = "t27/t27f"; -pub const NAME : str = "T27F Topic Engine"; +pub const NAME : str = "T27F Visual Spec"; pub const REPO : str = "t27"; pub const SOURCE : str = "SKILL.md"; -pub const SUMMARY_EN : str = "Turn a topic or client brief into three lenses, a 27-lesson map, one Bee task and a verified artifact"; +pub const SUMMARY_EN : str = "Show a .t27 spec as one synchronized model with many views, every node labelled exact, derived, suggested or unknown"; ; The frontmatter id is the slash command. pub const COMMAND : str = "/t27f"; -; Specs this skill stands on. -pub const SPECS : [1]str = ["specs/t27f/topic_engine.t27"]; -pub const TAGS : [3]str = ["t27f", "learning", "bees"]; +; Specs this skill stands on: the T27F UI plan IR, then the topic-map application. +pub const SPECS : [2]str = ["specs/t27f/ui_plan.t27", "specs/t27f/topic_engine.t27"]; +pub const TAGS : [3]str = ["t27f", "visual-spec", "specs"]; pub const ENABLED : bool = true; ; Default budget; SKILL.md declares no timeout of its own. pub const TIMEOUT_MIN : u16 = 30; @@ -27,14 +29,15 @@ pub const TIMEOUT_MIN : u16 = 30; test basic_constants { assert KIND == "skill"; assert ID == "t27/t27f"; - assert NAME == "T27F Topic Engine"; + assert NAME == "T27F Visual Spec"; assert REPO == "t27"; assert COMMAND == "/t27f"; assert ENABLED == true; assert TIMEOUT_MIN == 30; assert TAGS[0] == "t27f"; - assert TAGS[1] == "learning"; - assert TAGS[2] == "bees"; - assert SPECS.len == 1; - assert SPECS[0] == "specs/t27f/topic_engine.t27"; + assert TAGS[1] == "visual-spec"; + assert TAGS[2] == "specs"; + assert SPECS.len == 2; + assert SPECS[0] == "specs/t27f/ui_plan.t27"; + assert SPECS[1] == "specs/t27f/topic_engine.t27"; } diff --git a/specs/t27f/topic_engine.t27 b/specs/t27f/topic_engine.t27 index d01c99aea2..9a26c5d740 100644 --- a/specs/t27f/topic_engine.t27 +++ b/specs/t27f/topic_engine.t27 @@ -1,6 +1,8 @@ // SPDX-License-Identifier: Apache-2.0 -; specs/t27f/topic_engine.t27 -- the T27F topic-to-value engine, phase 1 vertical slice -; (gHashTag/trinity#1677, parent epic gHashTag/trinity#1648). +; specs/t27f/topic_engine.t27 -- the topic-to-value application, phase 1 vertical slice +; (gHashTag/trinity#1677). It is an application built on T27F, not T27F itself: T27F is the visual +; spec of a .t27 file (gHashTag/trinity#1648, RFC gHashTag/trinity#1649); the definition lives in +; `.claude/skills/t27f/SKILL.md`. ; A topic or a client brief goes in; out come three lenses, a map of 27 lessons, one relevant Bee ; task, an artifact that is verified before it counts, and a progression event. The same functions ; serve every domain: a villa sale and a GF16 research note walk the same 27 steps.