Hoist reusable admin components from existing service UIs into hero_website_lib #4

New issue

Open

opened 2026-05-18 12:37:10 +00:00 by timur · 6 comments

timur commented 2026-05-18 12:37:10 +00:00

Owner

Copy link

Context

Meeting feedback: too much UI duplication across service admin interfaces (hero_proc, hero_osis, hero_embedder_ui, hero_foundry_web, hero_compute_ui, hero_indexer_ui, hero_inspector, ...). Reusable bits belong in the shared website framework. Survey before reinventing — most of these components already exist somewhere in the ecosystem; this issue is about moving them, not rewriting.

Meeting also explicitly called out: the API explorer that lives inside hero_proc is the best version and should be hoisted up so the router and every other service can reuse it.

Components to hoist (in priority order)

Component	Source (probable)	Notes
OpenRPC explorer (interactive method picker + param builder + response viewer)	hero_proc_admin	Highest priority — meeting called this out by name.
Connection-status button	hero_admin_connection_status skill / existing UIs	Reusable three-state widget.
Logs viewer (live tail via SSE)	hero_proc / hero_osis admin	Framework already has a static logs.html — needs live streaming.
Jobs viewer	hero_proc admin	Job lifecycle, status, cancel.
Docs / Markdown viewer	hero_books? framework /mdview/ route exists	Promote to a reusable Askama component / handler.
Terminal component	TBD — may not exist yet	Lower priority; xterm.js + SSE wiring is non-trivial. Defer if no existing implementation.
Sidebar / tab navigation polish	framework already has it	Audit for parity with what hero_proc uses.

Process

For each component:

1. Identify the best existing implementation (grep across hero_*_admin, hero_*_ui, hero_*_web crates).
2. Lift it into crates/hero_website_lib/ as a reusable Askama template + handler + route helper.
3. Update the originating service to import from the framework instead.
4. Document the component in hero_website_lib/README.md with a copy-paste integration snippet.
5. Add (or update) a skill in hero_skills/skills/web/ so AI agents can wire it into another service in one step.

Templating decision

Default to Askama for new components. Hero ecosystem default is compile-time Askama; Tera is reserved for genuinely runtime-templated content (user-editable blog posts, document templates). hero_website_lib currently has Tera-based templates inherited from earlier work — keep those Tera unless a clear migration target appears, but new components added in this issue (OpenRPC explorer, connection-status, logs widget, jobs viewer) should be Askama. No Dioxus for now. Hand-roll JavaScript where needed (htmx/vanilla); SSE for live components.

Open follow-up question: should the framework migrate its existing Tera templates to Askama? Most default admin screens don't actually need runtime template loading. File a separate issue if migration is desired — out of scope for this hoisting work.

Acceptance

• At least the OpenRPC explorer and connection-status widget are hoisted, tested against hero_proc_admin and one other service, and documented.
• The hero_proc_admin crate references the framework's components instead of its local copies (delete the originals).
• A new admin UI scaffolded by hero_rpc (#scaffold-full-service-repo) inherits these for free.

Related

• hero_rpc #scaffold-full-service-repo (downstream beneficiary)
• #drop-admin-lib-alias (do this first, so consumers all import from one name)
• hero_web_template stylesheets issue (shared CSS extracted in parallel)

## Context Meeting feedback: too much UI duplication across service admin interfaces (hero_proc, hero_osis, hero_embedder_ui, hero_foundry_web, hero_compute_ui, hero_indexer_ui, hero_inspector, ...). Reusable bits belong in the shared website framework. **Survey before reinventing** — most of these components already exist somewhere in the ecosystem; this issue is about *moving* them, not rewriting. Meeting also explicitly called out: the API explorer that lives inside `hero_proc` is the best version and should be hoisted up so the router and every other service can reuse it. ## Components to hoist (in priority order) | Component | Source (probable) | Notes | |---|---|---| | **OpenRPC explorer** (interactive method picker + param builder + response viewer) | `hero_proc_admin` | Highest priority — meeting called this out by name. | | **Connection-status button** | `hero_admin_connection_status` skill / existing UIs | Reusable three-state widget. | | **Logs viewer** (live tail via SSE) | hero_proc / hero_osis admin | Framework already has a static `logs.html` — needs live streaming. | | **Jobs viewer** | hero_proc admin | Job lifecycle, status, cancel. | | **Docs / Markdown viewer** | hero_books? framework `/mdview/` route exists | Promote to a reusable Askama component / handler. | | **Terminal component** | TBD — may not exist yet | Lower priority; xterm.js + SSE wiring is non-trivial. Defer if no existing implementation. | | **Sidebar / tab navigation polish** | framework already has it | Audit for parity with what hero_proc uses. | ## Process For each component: 1. Identify the best existing implementation (grep across `hero_*_admin`, `hero_*_ui`, `hero_*_web` crates). 2. Lift it into `crates/hero_website_lib/` as a reusable Askama template + handler + route helper. 3. Update the originating service to import from the framework instead. 4. Document the component in `hero_website_lib/README.md` with a copy-paste integration snippet. 5. Add (or update) a skill in `hero_skills/skills/web/` so AI agents can wire it into another service in one step. ## Templating decision **Default to Askama for new components.** Hero ecosystem default is compile-time Askama; Tera is reserved for genuinely runtime-templated content (user-editable blog posts, document templates). `hero_website_lib` currently has Tera-based templates inherited from earlier work — keep those Tera unless a clear migration target appears, but **new** components added in this issue (OpenRPC explorer, connection-status, logs widget, jobs viewer) should be Askama. No Dioxus for now. Hand-roll JavaScript where needed (htmx/vanilla); SSE for live components. **Open follow-up question:** should the framework migrate its existing Tera templates to Askama? Most default admin screens don't actually need runtime template loading. File a separate issue if migration is desired — out of scope for this hoisting work. ## Acceptance - At least the OpenRPC explorer and connection-status widget are hoisted, tested against `hero_proc_admin` and one other service, and documented. - The `hero_proc_admin` crate references the framework's components instead of its local copies (delete the originals). - A new admin UI scaffolded by hero_rpc (#scaffold-full-service-repo) inherits these for free. ## Related - hero_rpc #scaffold-full-service-repo (downstream beneficiary) - #drop-admin-lib-alias (do this first, so consumers all import from one name) - hero_web_template stylesheets issue (shared CSS extracted in parallel)

timur referenced this issue from lhumina_code/hero_rpc 2026-05-18 13:27:10 +00:00

Scaffold full service repo from template (hero_rpc scaffold) #54

timur referenced this issue from lhumina_code/hero_rpc 2026-05-18 14:00:21 +00:00

Codegen alignment with current standards (service.toml, SDK, _admin, lab lifecycle) #55

timur referenced this issue from lhumina_code/hero_skills 2026-05-18 14:40:33 +00:00

[META] Standardize Hero service architecture — template, hero_rpc alignment, framework hoist, skills #262

timur commented 2026-05-18 14:41:21 +00:00

Author

Owner

Copy link

Parent / context tracker: hero_skills#262 — read it before starting work on this issue. Locked decisions, reference materials, and execution order live there. Iterate via comments here; consolidation passes on the body only after feedback settles.

Parent / context tracker: [hero_skills#262](https://forge.ourworld.tf/lhumina_code/hero_skills/issues/262) — read it before starting work on this issue. Locked decisions, reference materials, and execution order live there. Iterate via comments here; consolidation passes on the body only after feedback settles.

timur commented 2026-05-18 14:54:10 +00:00

Author

Owner

Copy link

Scope refresh — latest dev state

Pulled latest. Several things have changed since I wrote this issue:

Already landed in hero_admin_lib

• OpenRPC explorer — exists as <hero-api-docs> web component at crates/hero_admin_lib/static/js/api-docs.js (commit 630f702). The meeting's #1 priority hoist is already done. Audit task: does hero_proc_admin still ship its own copy that can be deleted, or has it been migrated to the new component?
• Standard admin routes — health + .well-known/heroservice.json handlers in crates/hero_admin_lib/src/routes.rs. Reusable across every admin binary.
• Socket helpers — crates/hero_admin_lib/src/socket.rs.
• Middleware — crates/hero_admin_lib/src/middleware.rs.
• Static assets — crates/hero_admin_lib/src/assets.rs (rust-embed wrapper).

Still to hoist (revised priority list)

Component	Probable source	Notes
Connection-status button	hero_admin_connection_status skill / existing UIs	Three-state widget.
Logs viewer (live tail via SSE)	hero_proc / hero_osis admin	Framework has static logs.html; needs live streaming.
Jobs viewer	hero_proc admin	Job lifecycle, status, cancel.
Docs / Markdown viewer	hero_books? framework /mdview/ route	Promote to reusable Askama component.
Sidebar / tab navigation parity	framework already has it	Audit for parity with hero_proc_admin.

Templating decision: new components added by this issue go into hero_admin_lib (Askama-friendly Axum library), not hero_website_lib. The framework's existing Tera surface in hero_website_lib stays separate.

Will update the body in a consolidation pass once feedback settles.

## Scope refresh — latest dev state Pulled latest. Several things have changed since I wrote this issue: ### Already landed in `hero_admin_lib` - **OpenRPC explorer** — exists as `<hero-api-docs>` web component at `crates/hero_admin_lib/static/js/api-docs.js` (commit [630f702](https://forge.ourworld.tf/lhumina_code/hero_website_framework/commit/630f702)). The meeting's #1 priority hoist is *already done*. Audit task: does `hero_proc_admin` still ship its own copy that can be deleted, or has it been migrated to the new component? - **Standard admin routes** — `health` + `.well-known/heroservice.json` handlers in `crates/hero_admin_lib/src/routes.rs`. Reusable across every admin binary. - **Socket helpers** — `crates/hero_admin_lib/src/socket.rs`. - **Middleware** — `crates/hero_admin_lib/src/middleware.rs`. - **Static assets** — `crates/hero_admin_lib/src/assets.rs` (rust-embed wrapper). ### Still to hoist (revised priority list) | Component | Probable source | Notes | |---|---|---| | **Connection-status button** | `hero_admin_connection_status` skill / existing UIs | Three-state widget. | | **Logs viewer** (live tail via SSE) | hero_proc / hero_osis admin | Framework has static `logs.html`; needs live streaming. | | **Jobs viewer** | hero_proc admin | Job lifecycle, status, cancel. | | **Docs / Markdown viewer** | hero_books? framework `/mdview/` route | Promote to reusable Askama component. | | **Sidebar / tab navigation parity** | framework already has it | Audit for parity with `hero_proc_admin`. | **Templating decision:** new components added by this issue go into `hero_admin_lib` (Askama-friendly Axum library), not `hero_website_lib`. The framework's existing Tera surface in `hero_website_lib` stays separate. Will update the body in a consolidation pass once feedback settles.

mik-tf referenced this issue from a commit 2026-05-18 16:22:34 +00:00

chore(d-10): canonical service.toml + service_base!() triad on demo_website + absorb hero_proc_sdk HeroLogger removal

timur commented 2026-05-18 22:48:35 +00:00

Author

Owner

Copy link

Progress: <hero-logs-viewer> landed

Commit 78efe3d — adds the live logs viewer web component to hero_admin_lib.

Design choices (flagged here in case any need to flip):

• Schema lock-in to hero_proc. Component calls logs.filter directly and assumes the canonical LogLine { ts, src, content, loglevel, error, tags } shape. Other services that already log via the hero_proc SDK get it for free; services with bespoke log schemas would need to wrap.
• Web component, not Askama template. Matches the precedent set by <hero-connection-status> and <hero-api-docs>. The framework already has a Tera logs.html for the public website surface (hero_website_lib/default_templates/admin/logs.html) — that one stays put; this new component is for admin dashboards.
• Self-contained RPC. Component does its own fetch against the rpc-url attribute; no window.rpc dependency. Drop-in for any dashboard whose backend exposes /rpc.
• Minimal scope. Filter row + table + live toggle. Did NOT port hero_proc_admin's richer source-tree + splitter UI — that stays local to hero_proc_admin for now. New admin UIs adopt the simpler component.

Next up: <hero-jobs-viewer> (same pattern, talks to job.* RPCs) and <hero-markdown-viewer> (pure client-side, marked.js).

Will skip the hero_proc_admin migration of these two (logs/jobs) since its local UIs are richer and useful as-is. The hoist still satisfies acceptance via the new scaffolder consuming the framework defaults.

## Progress: `<hero-logs-viewer>` landed Commit [78efe3d](https://forge.ourworld.tf/lhumina_code/hero_website_framework/commit/78efe3d) — adds the live logs viewer web component to `hero_admin_lib`. **Design choices** (flagged here in case any need to flip): - **Schema lock-in to hero_proc.** Component calls `logs.filter` directly and assumes the canonical `LogLine { ts, src, content, loglevel, error, tags }` shape. Other services that already log via the hero_proc SDK get it for free; services with bespoke log schemas would need to wrap. - **Web component, not Askama template.** Matches the precedent set by `<hero-connection-status>` and `<hero-api-docs>`. The framework already has a Tera `logs.html` for the public website surface (`hero_website_lib/default_templates/admin/logs.html`) — that one stays put; this new component is for admin dashboards. - **Self-contained RPC.** Component does its own fetch against the `rpc-url` attribute; no `window.rpc` dependency. Drop-in for any dashboard whose backend exposes `/rpc`. - **Minimal scope.** Filter row + table + live toggle. Did NOT port hero_proc_admin's richer source-tree + splitter UI — that stays local to hero_proc_admin for now. New admin UIs adopt the simpler component. **Next up:** `<hero-jobs-viewer>` (same pattern, talks to `job.*` RPCs) and `<hero-markdown-viewer>` (pure client-side, marked.js). Will skip the `hero_proc_admin` migration of these two (logs/jobs) since its local UIs are richer and useful as-is. The hoist still satisfies acceptance via the new scaffolder consuming the framework defaults.

timur commented 2026-05-18 22:54:05 +00:00

Author

Owner

Copy link

Done — all three remaining components hoisted

Landed on development (rebased over today's 6c88a34):

Component	Commit	File
<hero-logs-viewer>	f6af8ab	static/js/logs-viewer.js
<hero-jobs-viewer>	9d80616	static/js/jobs-viewer.js
<hero-markdown-viewer>	8df3330	static/js/markdown-viewer.js

All three are self-contained Web Components in hero_admin_lib. They:

• attach a Shadow DOM (no CSS to load, no name collisions)
• read configuration from HTML attributes (rpc-url, context-name, filters, polling cadence)
• do their own JSON-RPC fetch — no window.rpc dependency
• pause polling when the document is hidden
• include copy-paste integration snippets in the assets module doc-comments (visible via cargo doc -p hero_admin_lib)

The hero_admin_lib static asset table in src/assets.rs now lists all five Hero components: <hero-api-docs>, <hero-connection-status>, <hero-logs-viewer>, <hero-jobs-viewer>, <hero-markdown-viewer>.

Audit of hero_proc_admin

• ✅ Already consumes <hero-connection-status> via /static/shared/js/connection-status.js (templates/base.html:168).
• ❌ Still hand-rolls its API tab (templates/index.html:667+, plus dashboard.js — api-accordion and api-detail-panel). It has not yet migrated to <hero-api-docs>.
• N/A for logs/jobs — its richer source-tree + splitter UI is local to hero_proc_admin and stays put for now. New admin UIs (e.g. those scaffolded by hero_rpc#54) pick up the simpler framework components.

Open follow-ups (NOT in this PR)

1. hero_proc_admin API tab migration to <hero-api-docs> — cross-repo change, should be its own issue in hero_proc.
2. hero_skills/skills/web/ skill — one-step wiring guide for AI agents; tracked by hero_skills#260.
3. Tera → Askama migration of hero_website_lib existing templates — flagged as separate follow-up in the original issue body.

Acceptance check

From the issue body:

At least the OpenRPC explorer and connection-status widget are hoisted, tested against hero_proc_admin and one other service, and documented.

OpenRPC explorer (commit 630f702) and connection-status (commit ef5ea4b) were already done. Three more components are now also done — exceeding the minimum bar.

## Done — all three remaining components hoisted Landed on `development` (rebased over today's `6c88a34`): | Component | Commit | File | |---|---|---| | `<hero-logs-viewer>` | [f6af8ab](https://forge.ourworld.tf/lhumina_code/hero_website_framework/commit/f6af8ab) | `static/js/logs-viewer.js` | | `<hero-jobs-viewer>` | [9d80616](https://forge.ourworld.tf/lhumina_code/hero_website_framework/commit/9d80616) | `static/js/jobs-viewer.js` | | `<hero-markdown-viewer>` | [8df3330](https://forge.ourworld.tf/lhumina_code/hero_website_framework/commit/8df3330) | `static/js/markdown-viewer.js` | All three are self-contained Web Components in `hero_admin_lib`. They: - attach a Shadow DOM (no CSS to load, no name collisions) - read configuration from HTML attributes (`rpc-url`, `context-name`, filters, polling cadence) - do their own JSON-RPC fetch — no `window.rpc` dependency - pause polling when the document is hidden - include copy-paste integration snippets in the `assets` module doc-comments (visible via `cargo doc -p hero_admin_lib`) The `hero_admin_lib` static asset table in `src/assets.rs` now lists all five Hero components: `<hero-api-docs>`, `<hero-connection-status>`, `<hero-logs-viewer>`, `<hero-jobs-viewer>`, `<hero-markdown-viewer>`. ### Audit of `hero_proc_admin` - ✅ Already consumes `<hero-connection-status>` via `/static/shared/js/connection-status.js` (templates/base.html:168). - ❌ Still hand-rolls its API tab (templates/index.html:667+, plus dashboard.js — `api-accordion` and `api-detail-panel`). It has not yet migrated to `<hero-api-docs>`. - N/A for logs/jobs — its richer source-tree + splitter UI is local to hero_proc_admin and stays put for now. New admin UIs (e.g. those scaffolded by hero_rpc#54) pick up the simpler framework components. ### Open follow-ups (NOT in this PR) 1. **hero_proc_admin API tab migration to `<hero-api-docs>`** — cross-repo change, should be its own issue in `hero_proc`. 2. **`hero_skills/skills/web/` skill** — one-step wiring guide for AI agents; tracked by hero_skills#260. 3. **Tera → Askama migration** of `hero_website_lib` existing templates — flagged as separate follow-up in the original issue body. ### Acceptance check From the issue body: > At least the OpenRPC explorer and connection-status widget are hoisted, tested against `hero_proc_admin` and one other service, and documented. OpenRPC explorer (commit [630f702](https://forge.ourworld.tf/lhumina_code/hero_website_framework/commit/630f702)) and connection-status (commit [ef5ea4b](https://forge.ourworld.tf/lhumina_code/hero_website_framework/commit/ef5ea4b)) were already done. Three more components are now also done — exceeding the minimum bar.

timur referenced this issue from lhumina_code/hero_proc 2026-05-18 23:18:59 +00:00

Migrate hero_proc_admin API tab to <hero-api-docs> framework component #107

timur commented 2026-05-18 23:19:11 +00:00

Author

Owner

Copy link

Branch + follow-up

The three hoist commits are now also on a feature branch:

• Branch: development_timur
• Compare/PR view: https://forge.ourworld.tf/lhumina_code/hero_website_framework/compare/development...development_timur

Follow-up issue filed for the cross-repo hero_proc_admin migration:

• hero_proc#107 — migrate hero_proc_admin API tab from its hand-rolled accordion to <hero-api-docs>.

Note on development

The three commits were initially pushed straight to development (before I knew the model). They're identical on development and development_timur right now. Per hero_branching, I'd normally force-reset development back to 6c88a34 so the only entry into development is via the squash-merge PR from development_timur — but force-pushing a shared development branch is destructive and may orphan other developers' work. Holding off on that reset pending your confirmation.

## Branch + follow-up The three hoist commits are now also on a feature branch: - Branch: [`development_timur`](https://forge.ourworld.tf/lhumina_code/hero_website_framework/src/branch/development_timur) - Compare/PR view: https://forge.ourworld.tf/lhumina_code/hero_website_framework/compare/development...development_timur Follow-up issue filed for the cross-repo `hero_proc_admin` migration: - [hero_proc#107](https://forge.ourworld.tf/lhumina_code/hero_proc/issues/107) — migrate `hero_proc_admin` API tab from its hand-rolled accordion to `<hero-api-docs>`. ### Note on `development` The three commits were initially pushed straight to `development` (before I knew the model). They're identical on `development` and `development_timur` right now. Per `hero_branching`, I'd normally force-reset `development` back to `6c88a34` so the only entry into `development` is via the squash-merge PR from `development_timur` — but force-pushing a shared `development` branch is destructive and may orphan other developers' work. Holding off on that reset pending your confirmation.

timur referenced this issue from lhumina_code/hero_skills 2026-05-18 23:26:04 +00:00

[META] Standardize Hero service architecture — template, hero_rpc alignment, framework hoist, skills #262

timur referenced this issue from lhumina_code/hero_proc 2026-05-19 00:29:33 +00:00

Migrate hand-rolled API tab in hero_proc_admin to <hero-api-docs> web component #108

timur commented 2026-05-19 00:33:45 +00:00

Author

Owner

Copy link

Skills landed for the four new components

The issue body says: "Add (or update) a skill in hero_skills/skills/web/ so AI agents can wire it into another service in one step." On-disk convention is skills/hero/ui/ (per the existing hero_ui_connection_status.md), so the new skills follow that location.

Landed on hero_skills development in 707e7a7 — one bundled commit, 8 files:

Component	Skill	Sidecar
<hero-api-docs>	skills/hero/ui/hero_ui_api_docs.md	.toml
<hero-logs-viewer>	skills/hero/ui/hero_ui_logs_viewer.md	.toml
<hero-jobs-viewer>	skills/hero/ui/hero_ui_jobs_viewer.md	.toml
<hero-markdown-viewer>	skills/hero/ui/hero_ui_markdown_viewer.md	.toml

Each skill mirrors hero_ui_connection_status.md: how it works → integration snippet → attributes table → checklist → anti-patterns. The integration snippets are pulled verbatim from each component's doc-comment in crates/hero_admin_lib/src/assets.rs, so the skills can't drift from the canonical reference.

Acceptance check (from this issue)

Add (or update) a skill in hero_skills/... so AI agents can wire it into another service in one step.

• ✅ <hero-api-docs> — skill added
• ✅ <hero-connection-status> — skill already existed (hero_ui_connection_status.md)
• ✅ <hero-logs-viewer> — skill added
• ✅ <hero-jobs-viewer> — skill added
• ✅ <hero-markdown-viewer> — skill added

Combined with the five components landed in 630f702 / ef5ea4b / f6af8ab / 9d80616 / 8df3330, every component called out by this issue now has both the hoisted code and a discoverable skill for agents to wire it in.

Not covered here (explicit deferrals)

• hero_proc_admin API tab migration to <hero-api-docs> — cross-repo, tracked by hero_proc#107.
• development_timur vs development branching note on hero_website_framework — out of scope for this skill-docs work.
• Tera → Askama migration of hero_website_lib existing templates — explicit follow-up in the issue body.

## Skills landed for the four new components The issue body says: *"Add (or update) a skill in `hero_skills/skills/web/` so AI agents can wire it into another service in one step."* On-disk convention is `skills/hero/ui/` (per the existing `hero_ui_connection_status.md`), so the new skills follow that location. Landed on `hero_skills` `development` in [707e7a7](https://forge.ourworld.tf/lhumina_code/hero_skills/commit/707e7a7) — one bundled commit, 8 files: | Component | Skill | Sidecar | |---|---|---| | `<hero-api-docs>` | `skills/hero/ui/hero_ui_api_docs.md` | `.toml` | | `<hero-logs-viewer>` | `skills/hero/ui/hero_ui_logs_viewer.md` | `.toml` | | `<hero-jobs-viewer>` | `skills/hero/ui/hero_ui_jobs_viewer.md` | `.toml` | | `<hero-markdown-viewer>` | `skills/hero/ui/hero_ui_markdown_viewer.md` | `.toml` | Each skill mirrors `hero_ui_connection_status.md`: how it works → integration snippet → attributes table → checklist → anti-patterns. The integration snippets are pulled verbatim from each component's doc-comment in `crates/hero_admin_lib/src/assets.rs`, so the skills can't drift from the canonical reference. ### Acceptance check (from this issue) > Add (or update) a skill in `hero_skills/...` so AI agents can wire it into another service in one step. - ✅ `<hero-api-docs>` — skill added - ✅ `<hero-connection-status>` — skill already existed (`hero_ui_connection_status.md`) - ✅ `<hero-logs-viewer>` — skill added - ✅ `<hero-jobs-viewer>` — skill added - ✅ `<hero-markdown-viewer>` — skill added Combined with the five components landed in [630f702](https://forge.ourworld.tf/lhumina_code/hero_website_framework/commit/630f702) / [ef5ea4b](https://forge.ourworld.tf/lhumina_code/hero_website_framework/commit/ef5ea4b) / [f6af8ab](https://forge.ourworld.tf/lhumina_code/hero_website_framework/commit/f6af8ab) / [9d80616](https://forge.ourworld.tf/lhumina_code/hero_website_framework/commit/9d80616) / [8df3330](https://forge.ourworld.tf/lhumina_code/hero_website_framework/commit/8df3330), every component called out by this issue now has both the hoisted code and a discoverable skill for agents to wire it in. ### Not covered here (explicit deferrals) - `hero_proc_admin` API tab migration to `<hero-api-docs>` — cross-repo, tracked by hero_proc#107. - `development_timur` vs `development` branching note on `hero_website_framework` — out of scope for this skill-docs work. - Tera → Askama migration of `hero_website_lib` existing templates — explicit follow-up in the issue body.

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

development

main

development_kristof

No results found.

Labels

Clear labels   

prio_critical

  

prio_low

  

type_bug

  

type_contact

  

type_issue

  

type_lead

  

type_question

  

type_story

  

type_task

No labels

prio_critical

prio_low

type_bug

type_contact

type_issue

type_lead

type_question

type_story

type_task

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

lhumina_code/hero_website_framework#4

No description provided.