Fix audit findings on the Astro port

- HIGH: graph island fetched /lokfgraph.json (BASE_URL has no trailing
  slash) — join with a slash so it fetches /lokf/graph.json; the dev server
  masked this, the built site was broken
- HIGH: restore dropped sections on guide/concepts (Bundle structure + the
  root index.md frontmatter + Body) — the POC page had been abbreviated
- HIGH: getting-started 'Work on the docs' now shows the Astro npm commands,
  not the removed mkdocs stack
- MED: re-add the 'Draft profile / not affiliated with Google' disclaimer to
  the home page (Starlight Aside) + restore the 'concept at a glance'
  example (surfacing the previously-orphaned concept-glance partial)
- MED: README docs link -> the real deploy host www.nolan-nichols.com/lokf/
- tutorial 'Visualize it' now points at lokf serve + lokf export, not the
  removed MkDocs hook

Links + security audit came back clean. astro build green (21 pages);
verified in-browser the graph fetches /lokf/graph.json (200, 6 nodes).

Author: nicholsn

README.md

@@ -9,7 +9,7 @@ ontology are all generated from that single source.
 
 > One sentence: *write OKF markdown, get a queryable knowledge graph for free.*
 
-**Documentation:** <https://lokf.nolan-nichols.com/>
+**Documentation:** <https://www.nolan-nichols.com/lokf/>
 
 ## Why
 

web/src/components/KnowledgeGraph.astro

@@ -5,7 +5,10 @@
 // node opens its details. Themed with Starlight's CSS variables.
 ---
 
-<div class="lokf-graph" data-graph-src={import.meta.env.BASE_URL + "graph.json"}>
+<div
+  class="lokf-graph"
+  data-graph-src={import.meta.env.BASE_URL.replace(/\/$/, "") + "/graph.json"}
+>
   <div class="lokf-graph__controls">
     <input
       type="search"

web/src/content/docs/getting-started.mdx

@@ -91,12 +91,16 @@ just docs-build  # strict build, exactly as CI runs it
 ```
 
 </TabItem>
-<TabItem label="uv">
+<TabItem label="npm">
 
 ```bash
-uv run --group docs mkdocs serve
-uv run --group docs mkdocs build --strict
+cd web && npm install && npm run dev    # live-reloading dev server
+cd web && npm ci && npm run build       # strict build, exactly as CI runs it
 ```
 
 </TabItem>
 </Tabs>
+
+The docs site is an [Astro Starlight](https://starlight.astro.build/) project
+in `web/`; the graph data and API reference are generated from the `lokf`
+package by a prebuild step.

web/src/content/docs/guide/concepts.mdx

@@ -1,6 +1,8 @@
 ---
 title: Bundles & concepts
 description: How a LOKF bundle is laid out and what a concept looks like.
+sidebar:
+  order: 1
 ---
 
 import { Content as CoreFields } from "../../../generated/core-fields-table.md";
@@ -9,24 +11,61 @@ LOKF keeps OKF's authoring model intact: a **knowledge bundle** is a directory
 tree of markdown files, each file describing one **concept** with a small YAML
 frontmatter block. Everything here is readable with `cat` and diffable in git.
 
+## Bundle structure
+
+Identical to OKF §3. `index.md` and `log.md` remain reserved; distribution as a
+git repo is recommended. LOKF adds **optional keys to the bundle-root
+`index.md` frontmatter** — the one place OKF already permits frontmatter in an
+index:
+
+```yaml title="index.md (bundle root)"
+---
+lokf_version: "0.1"          # LOKF version this bundle targets
+okf_version: "0.1"           # OKF version it remains compatible with
+base_iri: https://acme.example/knowledge/     # resolves Concept IDs to Concept IRIs
+context: https://w3id.org/lokf/context.jsonld # the @context to attach to concepts
+title: Acme Knowledge Bundle
+description: Canonical, agent-readable knowledge for Acme's data org.
+license: https://creativecommons.org/licenses/by/4.0/
+publisher:
+  type: Organization
+  id: https://acme.example
+  name: Acme Corp
+---
+```
+
+:::note[Plain OKF consumers are unaffected]
+A consumer that ignores these keys sees a perfectly ordinary OKF bundle. A
+semantic consumer uses `base_iri` + `context` to lift the whole bundle into RDF.
+:::
+
 ## Concept documents
 
 Every concept is a UTF-8 markdown file: a YAML **frontmatter** block followed
 by a markdown **body**, exactly as in OKF. LOKF specifies what the frontmatter
-keys *mean* by mapping each to an RDF property. `type` is the only required
-field; all others are optional.
+keys *mean* by mapping each to an RDF property.
+
+### Core frontmatter fields
+
+`type` is the only required field (as in OKF). All others are optional.
 
 <CoreFields />
 
 (`*` = multivalued.)
 
-:::note[Permissive by design]
+:::tip[Permissive by design]
 Producers MAY add any other keys; consumers MUST preserve unknown keys and
-MUST NOT reject documents that carry them. Missing optional fields, unknown
-`type` values, and broken cross-links MUST NOT cause rejection either.
+MUST NOT reject documents that carry them (OKF §4.1). Missing optional fields,
+unknown `type` values, and broken cross-links MUST NOT cause rejection either.
 :::
 
+### Body
+
+Unchanged from OKF §4.2. Standard markdown, structural headings preferred. The
+conventional headings `# Schema`, `# Examples`, and `# Citations` retain their
+OKF meaning. The body is mapped to `schema:text` in the RDF projection.
+
 ## Next
 
 - Give links meaning with [typed relationships](/lokf/guide/relationships/).
-- See the whole vocabulary in the [type reference](/lokf/guide/types/).
+- Pick the right class from the [type vocabulary](/lokf/guide/types/).

web/src/content/docs/index.mdx

@@ -18,7 +18,8 @@ hero:
       variant: minimal
 ---
 
-import { Card, CardGrid } from '@astrojs/starlight/components';
+import { Card, CardGrid, Aside } from '@astrojs/starlight/components';
+import { Content as ConceptGlance } from '../../generated/concept-glance.md';
 
 LOKF keeps OKF's markdown-plus-frontmatter authoring model but binds every
 concept, field, and relationship to **schema.org, W3C DCAT, and W3C PROV-O**,
@@ -27,6 +28,15 @@ losslessly to **RDF**. The format is defined once in **LinkML**; the JSON-LD
 context, JSON Schema, SHACL shapes, and OWL ontology are all generated from
 that single source.
 
+## A concept at a glance
+
+Ordinary OKF markdown, where every key has a defined RDF meaning:
+
+<ConceptGlance />
+
+Attach the published `lokf.context.jsonld` and this expands to RDF triples
+using `schema:`, `prov:`, `dcterms:`, and `lokf:` predicates — no separate file.
+
 <CardGrid>
 	<Card title="Convert" icon="seti:markdown">
 		`lokf convert` projects a concept or a whole bundle to Turtle,
@@ -45,3 +55,11 @@ that single source.
 		toolkit.
 	</Card>
 </CardGrid>
+
+<Aside type="caution" title="Draft profile">
+	LOKF v0.1 is a **draft profile** and is **not affiliated with or endorsed by
+	Google**. "Open Knowledge Format" / "OKF" refer to the format published by
+	Google Cloud
+	([`GoogleCloudPlatform/knowledge-catalog`](https://github.com/GoogleCloudPlatform/knowledge-catalog));
+	LOKF extends it under its open terms.
+</Aside>

web/src/content/docs/toolkit/tutorial.mdx

@@ -281,14 +281,13 @@ json.dump(to_cytoscape(bundle), open("graph.json", "w"), indent=2)
 EOF
 ```
 
-This site feeds the same output to a small MkDocs hook
-([`docs/hooks/lokf_hooks.py`](https://github.com/nicholsn/lokf/blob/main/docs/hooks/lokf_hooks.py))
-that emits `assets/graph.json` at build time and renders it with Cytoscape.js
-— point the hook's bundle path at `mykb/` and you have a graph page for your
-own knowledge base. The same hook also injects the output of
-`lokf.export.dataset_search_jsonld()` — schema.org `Dataset` JSON-LD for each
-Dataset/Table concept — into the HTML, making your datasets discoverable by
-search engines.
+Or skip the file entirely: [`lokf serve mykb/`](/lokf/toolkit/serve/) publishes
+a live graph explorer (and a SPARQL endpoint) for your bundle with no build
+step. This documentation site uses the same projection — the
+[`lokf export`](/lokf/reference/api/) command emits `graph.json` and the
+schema.org `Dataset` JSON-LD (from `lokf.export.dataset_search_jsonld()`) that
+its knowledge-graph page and `<head>` consume, so your datasets are
+discoverable by search engines.
 
 ## Recap