Library module (standard Work) page
one per Work, by category · 47 Works: 18 research_question · 8 knowledge_system · 4 bundle · 3 project · 3 tool · 2 section · 2 agent_system · 2 capability_pack · 2 playbook · 2 application · 1 library
The page, rendered
this template composed from real data, inside the CRM shellOpen it full size: /t/U3/example/ · data: example.json · schema.json
Why this template exists
his words · the reading · the ceilings-
His words 0
verbatim, from
00_AGENT_ZERO/source/— never paraphrasedNo verbatim source on this page. -
Reading authored by the seat
His 16:36: 'for each of the modules like it'll be connected to the github repo front-end … even client stock will have the listing of the repos even if they private'; 16:50: 'different categories of modules … projects, niches, client, personal … all of that stuff was distilled already from intelligence, so it's just about getting eyes on that stuff now'.
Readers. Human: understand one thing and its 'sauce' in a minute. Agent: entry file, command, owner, verification line, then go.
- What is it and why does it matter?
- Where is the code, is it public?
- What can I use from it today (sauce)?
- How do I verify it works?
- Who owns it and when did they last write?
-
What this page may claim
Claim ceilingFacts from the registry record and the repo; 'why it matters' is authored and labelled as such; maturity from the record, not from prose.Data it rendersregistry/works/.json, releases, source_links, repos.json in the repo's .agents/, owners.log; type decides the section set (research_question → U5, project → U4, private → U11). PrivacyPublic unless the record is private → U11.Empty stateMissing 'sauce' → 'no assets registered' with the gls command; never filler.Agent entrydocs/module-page-template.md → src/build.mjs work page
Content contract
his twelve, 18:19; '—' means this family carries nothing thereWork name
section · type · maturity kicker + one-line what
why it matters (authored)
typed relationship map: repo, releases, people, questions, projects
repo + satellites with public/private/access/rights
research Works it rests on, one line each on what they mean
docs in the repo, dated
verification line + state
owner + last writeback
releases + writebacks
docs by date
the eight sections
Sections, in order · where it lives
- 1kicker: section/type/maturity
- 2title + why it matters (authored)
- 3repo + satellites cards with public/private/rights
- 4sauce: 3–7 real assets
- 5contents / capabilities
- 6agent quick-start: entry file, commands, owner, verification line
- 7evidence / limits / version
- 8related work
- Lives at
- /works/
/ (template on 1 of 47 today: siso-foundry, docs/module-page-template.md) - Instances
- one per Work, by category
- Count
- 47 Works: 18 research_question · 8 knowledge_system · 4 bundle · 3 project · 3 tool · 2 section · 2 agent_system · 2 capability_pack · 2 playbook · 2 application · 1 library
- Renders
- registry/works/
.json + releases + source_links; his categories 16:50: 'projects, niches, client, personal' → maps onto type + section; connected to the GitHub repo front end (repos.json) 'even if they private' - Theme
- accent by section
- Rail
- U0
- Needs
- U0 U2
- Links out
- U4 project U12 releases U14 person U16 decisions U17 seats
- Links in
- U2 U1 U4
What to rob
presentation only; licences keptFrom the Action Model sites (built from real data)
Components, exact locations (Luna inventory)
| Component | Where | Renders | How | Quality |
|---|---|---|---|---|
| Actionist grouped registry rail | system-map/nav.js:74-123,125-174; system-map/nav.css:27-177 | page-registry.json sections/pages, status, descriptions and route IDs | Copy nav.js/nav.css and feed a registry JSON with sections and pages. | good — complete persistent grouped navigation and active-route state |
| Command palette | system-map/nav.js:157-171,192-257; system-map/nav.css:183-200 | Registry page title, description, section, ID and keywords filtered by query | Copy the palette DOM/event handlers and point REGISTRY_URL at the Great Library route registry. | good — keyboard navigation, mouse selection, escape close, and command shortcut |
| Mobile nav drawer/backdrop | system-map/nav.js:136-155,176-189; system-map/nav.css:202-232 | Same registry routes as desktop rail with mobile open/close state | Copy mobile button, backdrop, and responsive CSS; reuse the same registry renderer. | good — responsive drawer has explicit close semantics and backdrop |
| Hero plus status panel | system-map/index.html:67-80; system-map/part-page.css:8-15; registry.css:3-12; industry.css:1-30; state.css:15-72; blueprint/index.html:246-258 | Title, thesis/lede, current posture, status, date, and source/generator metadata | Copy the two-column hero/status structure and feed title, summary, posture, and provenance fields. | good — consistently separates narrative from current state |
| Metric strip | system-map/index.html:81-84; system-map/part-page.css:40-43,72-75; blueprint/index.html:328-335; industries/law_firms/index.html:21; state/index.html:19-27 | Counts such as mapped parts, sources, observed slots, repos, cells, and open gaps | Copy metric cards and bind each value to a named registry or record count. | good — compact quantitative orientation with semantic labels |
| Status badge/chip | site/index.html:101-102; system-map/part-page.css:37-39,58-59; nav.css:151-153; blueprint/index.html:39-42 | Research state, maturity, qualification, sparse/observed posture, and live/open state | Copy chip CSS and feed an explicit status vocabulary, never inferred prose. | good — status is visually prominent and remains text-readable |
| Registry card grid | system-map/parts/index.html:19-34; system-map/registry.css:14-20; industry index:20; live artifacts index | ID, group/section, title, description, count/status, and open route | Copy registry-card grid and feed typed records with route, title, summary, and status. | good — reusable catalogue unit with strong hover/open affordance |
| Node detail card grid | system-map/part-page.css:19-26; generate-part-pages.mjs:144-158; industry.css:38-49; generate-industry-pages.mjs:137-144 | Owned scope, known findings, inputs, outputs, risks, and open questions | Copy node-card variants and feed arrays into labeled cards with wide/risk/lilac/mint classes. | good — flexible two-column/wide layout for heterogeneous records |
From the 21st.dev bank (his picks, his notes)
kind of nice, kind of simple, could be used somewhere in the operators thing. (Server management one was a bit shitty)Shaan · ui-bank note
Rob this project-detail-view composition for library module (standard work) page.
these breadcrumbs, the way they do them is just really niceShaan · ui-bank note
Rob this with-slash composition for library module (standard work) page.
drop-down agent plan, might be useful. We've done a really nice onboarding dropdown and our UI is better, but the way this component works is maybe slightly betterShaan · ui-bank note
Rob this agent-plan composition for library module (standard work) page.
glass blog card, just nice, could be reused on the operator sideShaan · ui-bank note
Rob this glass-blog-card-shadcnui composition for library module (standard work) page.
estimated time arrival, really interesting, don't know where we'd use it, love to have it. Progress bar could be useful in the operator app somewhereShaan · ui-bank note
Rob this estimated-arrival composition for library module (standard work) page.
Bank gaps: authored reasoning and repo rights/access semantics need bespoke content
Done when
facts have a receipt; the rest is proposaltemplates/U3/template.html composes parts; example.json is real data.https://github.com/sisodias/siso-shell/tree/main/templates/U3- Counts on this page come from plan/templates.json (6 Sep 18:36), not from a live registry query.
- 'Built' means the template folder exists and renders; the done-when line is the acceptance.