okf-cli 0.1.0__tar.gz

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.
@@ -0,0 +1,7 @@
1
+ .venv/
2
+ __pycache__/
3
+ *.pyc
4
+ .pytest_cache/
5
+ bundled/
6
+ dist/
7
+ *.egg-info/
okf_cli-0.1.0/LICENSE ADDED
@@ -0,0 +1,21 @@
1
+ MIT License
2
+
3
+ Copyright (c) 2026 Dheerapat Tookkane
4
+
5
+ Permission is hereby granted, free of charge, to any person obtaining a copy
6
+ of this software and associated documentation files (the "Software"), to deal
7
+ in the Software without restriction, including without limitation the rights
8
+ to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
9
+ copies of the Software, and to permit persons to whom the Software is
10
+ furnished to do so, subject to the following conditions:
11
+
12
+ The above copyright notice and this permission notice shall be included in all
13
+ copies or substantial portions of the Software.
14
+
15
+ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
16
+ IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
17
+ FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
18
+ AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
19
+ LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
20
+ OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
21
+ SOFTWARE.
@@ -0,0 +1,451 @@
1
+ # Open Knowledge Format (OKF)
2
+
3
+ **Version 0.1 — Draft**
4
+
5
+ OKF is an open, human- and agent-friendly format for representing
6
+ *knowledge* — the metadata, context, and curated insight that surrounds
7
+ data and systems. It is designed to be authored by people, generated by
8
+ agents, exchanged across organizations, and consumed by both.
9
+
10
+ The format is intentionally minimal: a directory of markdown files with
11
+ YAML frontmatter. There is no schema registry, no central authority, and
12
+ no required tooling. If you can `cat` a file, you can read OKF; if you
13
+ can `git clone` a repo, you can ship it.
14
+
15
+ ---
16
+
17
+ ## 1. Motivation
18
+
19
+ The space of knowledge representation for AI agents is evolving quickly,
20
+ and many incompatible conventions are emerging. OKF takes the position
21
+ that knowledge is best represented in commonly accessible, established
22
+ formats that are:
23
+
24
+ - **Readable** by humans without tooling.
25
+ - **Parseable** by agents without bespoke SDKs.
26
+ - **Diffable** in version control.
27
+ - **Portable** across tools, organizations, and time.
28
+
29
+ The format is minimally opinionated. It standardizes only the small set
30
+ of structural conventions needed to make a knowledge corpus
31
+ *self-describing* — anything beyond that is left to the producer.
32
+
33
+ ### Goals
34
+
35
+ 1. Define a universal format that **enrichment agents** can write into.
36
+ 2. Inform how **consumption agents** should read and traverse it.
37
+ 3. Facilitate **exchange** of knowledge across systems and organizations.
38
+ 4. Standardize the small number of **required** fields that must be
39
+ present for content to be meaningfully consumed.
40
+
41
+ ### Non-goals
42
+
43
+ - Defining a fixed taxonomy of concept types.
44
+ - Prescribing storage, serving, or query infrastructure.
45
+ - Replacing domain-specific schemas (Avro, Protobuf, OpenAPI, etc.) —
46
+ OKF *references* them; it does not subsume them.
47
+
48
+ ---
49
+
50
+ ## 2. Terminology
51
+
52
+ - **Knowledge Bundle** — A self-contained, hierarchical collection of
53
+ knowledge documents. The unit of distribution.
54
+ - **Concept** — A single unit of knowledge within a bundle. Represented
55
+ as one markdown document. May describe a tangible asset (a table, an
56
+ API), an abstract idea (a metric, a business process), or anything in
57
+ between.
58
+ - **Concept ID** — The path of the concept's file within the bundle,
59
+ with the `.md` suffix removed. For example, `tables/users.md` has
60
+ concept ID `tables/users`.
61
+ - **Frontmatter** — YAML metadata block delimited by `---` at the top of
62
+ a markdown file.
63
+ - **Body** — Everything in the file after the frontmatter.
64
+ - **Link** — A standard markdown link from one concept to another, used
65
+ to express relationships beyond the implicit parent/child hierarchy.
66
+ - **Citation** — A link from a concept to an external source that
67
+ supports a claim in the body.
68
+
69
+ ---
70
+
71
+ ## 3. Bundle Structure
72
+
73
+ A bundle is a directory tree of markdown files. The directory structure
74
+ is independent of the domain — producers organize concepts however makes
75
+ sense for the knowledge being captured.
76
+
77
+ ```
78
+ path/to/bundle/
79
+ ├── index.md # Optional. Directory listing for progressive disclosure.
80
+ ├── log.md # Optional. Chronological history of updates.
81
+ ├── <concept>.md # A concept at the bundle root.
82
+ └── <subdirectory>/ # Subdirectories organize concepts into groups.
83
+ ├── index.md
84
+ ├── <concept>.md
85
+ └── <subdirectory>/
86
+ └── …
87
+ ```
88
+
89
+ A bundle MAY be distributed as:
90
+
91
+ - A git repository (recommended — provides history, attribution, diffs).
92
+ - A tarball or zip archive of the directory.
93
+ - A subdirectory within a larger repository.
94
+
95
+ ### 3.1 Reserved filenames
96
+
97
+ The following filenames have defined meaning at any level of the
98
+ hierarchy and MUST NOT be used for concept documents:
99
+
100
+ | Filename | Purpose |
101
+ |--------------|--------------------------------------------------------|
102
+ | `index.md` | Directory listing. See §6. |
103
+ | `log.md` | Update history. See §7. |
104
+
105
+ All other `.md` files are concept documents.
106
+
107
+ Tags themselves remain a first-class concept — see the `tags`
108
+ frontmatter field in §4.1. OKF does not specify a separate file format
109
+ for aggregating documents by tag; producers that want a tag-browsing
110
+ view can synthesize one at consumption time by scanning frontmatter.
111
+
112
+ ---
113
+
114
+ ## 4. Concept Documents
115
+
116
+ Every concept is a UTF-8 markdown file. It has two parts:
117
+
118
+ 1. A **YAML frontmatter block**, delimited by `---` on its own line at
119
+ the start of the file and a closing `---` on its own line.
120
+ 2. A **markdown body**, containing free-form content.
121
+
122
+ ### 4.1 Frontmatter
123
+
124
+ ```yaml
125
+ ---
126
+ type: <Type name> # REQUIRED
127
+ title: <Optional display name>
128
+ description: <Optional one-line summary>
129
+ resource: <Optional canonical URI for the underlying asset>
130
+ tags: [<tag>, <tag>, …] # Optional
131
+ timestamp: <ISO 8601 datetime> # Optional last-modified time
132
+ # … other producer-defined key/value pairs
133
+ ---
134
+ ```
135
+
136
+ **Required:**
137
+
138
+ - `type` — A short string identifying the kind of concept. Consumers
139
+ use this for routing, filtering, and presentation. Example values:
140
+ `BigQuery Table`, `BigQuery Dataset`, `API Endpoint`, `Metric`,
141
+ `Playbook`, `Reference`.
142
+
143
+ Type values are **not** registered centrally. Producers SHOULD pick
144
+ values that are descriptive and self-explanatory; consumers MUST
145
+ tolerate unknown types gracefully (typically by treating them as
146
+ generic concepts).
147
+
148
+ **Recommended (in priority order):**
149
+
150
+ - `title` — Human-readable display name. If omitted, consumers MAY
151
+ derive a title from the filename.
152
+ - `description` — A single sentence summarizing the concept. Used by
153
+ `index.md` generators, search snippets, and previews.
154
+ - `resource` — A URI that uniquely identifies the underlying asset the
155
+ concept describes. Absent for concepts that describe abstract ideas
156
+ rather than physical resources.
157
+ - `tags` — A YAML list of short strings for cross-cutting categorization.
158
+ - `timestamp` — ISO 8601 datetime of last meaningful change.
159
+
160
+ **Extensions:** Producers MAY include any additional keys. Consumers
161
+ SHOULD preserve unknown keys when round-tripping and SHOULD NOT reject
162
+ documents with unrecognized fields.
163
+
164
+ ### 4.2 Body
165
+
166
+ The body is standard markdown. Producers SHOULD favor structural
167
+ markdown — headings, lists, tables, fenced code blocks — over freeform
168
+ prose, since structure aids both human reading and agent retrieval.
169
+
170
+ There are no required body sections. The following section headings have
171
+ **conventional** meaning and SHOULD be used when applicable:
172
+
173
+ | Heading | Purpose |
174
+ |----------------|--------------------------------------------------------|
175
+ | `# Schema` | Structured description of an asset's columns/fields. |
176
+ | `# Examples` | Concrete usage examples, often as fenced code blocks. |
177
+ | `# Citations` | External sources backing claims in the body. See §8. |
178
+
179
+ ### 4.3 Example: a concept bound to a resource
180
+
181
+ ```markdown
182
+ ---
183
+ type: BigQuery Table
184
+ title: Customer Orders
185
+ description: One row per completed customer order across all channels.
186
+ resource: https://console.cloud.google.com/bigquery?p=acme&d=sales&t=orders
187
+ tags: [sales, orders, revenue]
188
+ timestamp: 2026-05-28T14:30:00Z
189
+ ---
190
+
191
+ # Schema
192
+
193
+ | Column | Type | Description |
194
+ |---------------|-----------|------------------------------------------|
195
+ | `order_id` | STRING | Globally unique order identifier. |
196
+ | `customer_id` | STRING | Foreign key into [customers](/tables/customers.md). |
197
+ | `total_usd` | NUMERIC | Order total in US dollars. |
198
+ | `placed_at` | TIMESTAMP | When the customer submitted the order. |
199
+
200
+ # Joins
201
+
202
+ Joined with [customers](/tables/customers.md) on `customer_id`.
203
+
204
+ # Citations
205
+
206
+ [1] [BigQuery table schema](https://console.cloud.google.com/bigquery?p=acme&d=sales&t=orders)
207
+ ```
208
+
209
+ ### 4.4 Example: a concept not bound to a resource
210
+
211
+ ```markdown
212
+ ---
213
+ type: Playbook
214
+ title: Incident response — data freshness alert
215
+ description: Steps to triage a freshness alert on the orders pipeline.
216
+ tags: [oncall, incident]
217
+ timestamp: 2026-04-12T09:00:00Z
218
+ ---
219
+
220
+ # Trigger
221
+
222
+ A freshness alert fires when `orders` lags more than 30 minutes behind
223
+ its expected SLA. See the [orders table](/tables/orders.md).
224
+
225
+ # Steps
226
+
227
+ 1. Check the [ingestion job dashboard](https://example.com/dash).
228
+ 2. …
229
+ ```
230
+
231
+ ---
232
+
233
+ ## 5. Cross-linking
234
+
235
+ Concepts MAY link to other concepts using standard markdown links. Two
236
+ forms are supported:
237
+
238
+ ### 5.1 Absolute (bundle-relative) links
239
+
240
+ Begin with `/`, interpreted relative to the bundle root.
241
+
242
+ ```markdown
243
+ See the [customers table](/tables/customers.md) for the join key.
244
+ ```
245
+
246
+ This is the **recommended** form because it is stable when documents are
247
+ moved within their subdirectory.
248
+
249
+ ### 5.2 Relative links
250
+
251
+ Standard markdown relative paths.
252
+
253
+ ```markdown
254
+ See the [neighboring concept](./other.md).
255
+ ```
256
+
257
+ ### 5.3 Link semantics
258
+
259
+ A link from concept A to concept B asserts a *relationship*. The
260
+ specific kind of relationship (parent/child, references, joins-with,
261
+ depends-on, etc.) is conveyed by the surrounding prose, not by the link
262
+ itself. Consumers that build a graph view typically treat all links as
263
+ directed edges of an untyped relationship.
264
+
265
+ Consumers MUST tolerate broken links — a link whose target does not
266
+ exist in the bundle is not malformed; it may simply represent
267
+ not-yet-written knowledge.
268
+
269
+ ---
270
+
271
+ ## 6. Index Files
272
+
273
+ An `index.md` file MAY appear in any directory, including the bundle
274
+ root. It enumerates the directory's contents to support **progressive
275
+ disclosure** — letting a human or agent see what is available before
276
+ opening individual documents.
277
+
278
+ Index files contain no frontmatter. The body uses one or more sections,
279
+ each grouping concepts under a heading:
280
+
281
+ ```markdown
282
+ # Section / Group Heading
283
+
284
+ * [Title 1](relative-url-1) - short description of item 1
285
+ * [Title 2](relative-url-2) - short description of item 2
286
+
287
+ # Another Section
288
+
289
+ * [Subdirectory](subdir/) - short description of the subdirectory
290
+ ```
291
+
292
+ Entries SHOULD include the description from the linked concept's
293
+ frontmatter. Producers MAY generate `index.md` automatically; consumers
294
+ MAY synthesize one on the fly when none is present.
295
+
296
+ ---
297
+
298
+ ## 7. Log Files (optional)
299
+
300
+ A `log.md` file MAY appear at any level of the hierarchy to record the
301
+ history of changes to that scope. The format is a flat list of
302
+ date-grouped entries, newest first:
303
+
304
+ ```markdown
305
+ # Directory Update Log
306
+
307
+ ## 2026-05-22
308
+ * **Update**: Added new BigQuery table reference for [Customer Metrics](/tables/customer-metrics.md).
309
+ * **Creation**: Established the [Dataplex Playbook](/playbooks/dataplex.md).
310
+
311
+ ## 2026-05-15
312
+ * **Initialization**: Created foundational directory structure.
313
+ * **Update**: Added progressive-disclosure guidelines to the root [index](/index.md).
314
+ ```
315
+
316
+ Date headings MUST use ISO 8601 `YYYY-MM-DD` form. Log entries are
317
+ prose; the leading bold word (`**Update**`, `**Creation**`,
318
+ `**Deprecation**`, etc.) is a convention, not a requirement.
319
+
320
+ ---
321
+
322
+ ## 8. Citations
323
+
324
+ When a concept's body makes claims sourced from external material,
325
+ those sources SHOULD be listed under a `# Citations` heading at the
326
+ bottom of the document, numbered:
327
+
328
+ ```markdown
329
+ # Citations
330
+
331
+ [1] [BigQuery public dataset announcement](https://cloud.google.com/blog/products/data-analytics/...)
332
+ [2] [Internal data quality runbook](https://wiki.acme.internal/data/quality)
333
+ ```
334
+
335
+ Citation links MAY be absolute URLs, bundle-relative paths, or paths
336
+ into a `references/` subdirectory that mirrors external material as
337
+ first-class OKF concepts.
338
+
339
+ ---
340
+
341
+ ## 9. Conformance
342
+
343
+ A bundle is **conformant** with OKF v0.1 if:
344
+
345
+ 1. Every non-reserved `.md` file in the tree contains a parseable YAML
346
+ frontmatter block.
347
+ 2. Every frontmatter block contains a non-empty `type` field.
348
+ 3. Every reserved filename (`index.md`, `log.md`) follows the structure
349
+ described in §6 and §7 respectively when present.
350
+
351
+ Consumers SHOULD treat all other constraints as soft guidance. In
352
+ particular, consumers MUST NOT reject a bundle because of:
353
+
354
+ - Missing optional frontmatter fields.
355
+ - Unknown `type` values.
356
+ - Unknown additional frontmatter keys.
357
+ - Broken cross-links.
358
+ - Missing `index.md` files.
359
+
360
+ This permissive consumption model is intentional: OKF is meant to
361
+ remain useful as bundles grow, get refactored, and are partially
362
+ generated by agents.
363
+
364
+ ---
365
+
366
+ ## 10. Relationship to other formats
367
+
368
+ OKF is intentionally close to several established patterns:
369
+
370
+ - **LLM "wiki" repositories** that use markdown + frontmatter as
371
+ agent-readable knowledge bases.
372
+ - **Personal knowledge tools** like Obsidian and Notion, which use
373
+ hierarchical markdown with cross-links.
374
+ - **"Metadata as code"** approaches that store catalog metadata
375
+ alongside source code rather than in a separate registry.
376
+
377
+ OKF differs primarily in being **specified** — pinning down the small
378
+ set of rules needed for interoperability without dictating tooling.
379
+
380
+ ---
381
+
382
+ ## 11. Versioning
383
+
384
+ This document specifies OKF version **0.1**. Future revisions will be
385
+ versioned in the form `<major>.<minor>`:
386
+
387
+ - A **minor** version bump introduces backward-compatible additions
388
+ (new optional fields, new conventional section headings).
389
+ - A **major** version bump may make breaking changes (renaming required
390
+ fields, changing reserved filenames).
391
+
392
+ Bundles MAY declare the OKF version they target by including
393
+ `okf_version: "0.1"` in a bundle-root `index.md` frontmatter block (the
394
+ only place frontmatter is permitted in an `index.md`). Consumers that
395
+ do not understand the declared version SHOULD attempt best-effort
396
+ consumption rather than refusing the bundle.
397
+
398
+ ---
399
+
400
+ ## Appendix A — Minimal example bundle
401
+
402
+ ```
403
+ my_bundle/
404
+ ├── index.md
405
+ ├── datasets/
406
+ │ ├── index.md
407
+ │ └── sales.md
408
+ └── tables/
409
+ ├── index.md
410
+ ├── orders.md
411
+ └── customers.md
412
+ ```
413
+
414
+ `datasets/sales.md`:
415
+
416
+ ```markdown
417
+ ---
418
+ type: BigQuery Dataset
419
+ title: Sales
420
+ description: All sales-related tables for the retail business.
421
+ resource: https://console.cloud.google.com/bigquery?p=acme&d=sales
422
+ tags: [sales]
423
+ timestamp: 2026-05-28T00:00:00Z
424
+ ---
425
+
426
+ The sales dataset contains transactional tables, including
427
+ [orders](/tables/orders.md) and [customers](/tables/customers.md).
428
+ ```
429
+
430
+ `tables/orders.md`:
431
+
432
+ ```markdown
433
+ ---
434
+ type: BigQuery Table
435
+ title: Orders
436
+ description: One row per completed customer order.
437
+ resource: https://console.cloud.google.com/bigquery?p=acme&d=sales&t=orders
438
+ tags: [sales, orders]
439
+ timestamp: 2026-05-28T00:00:00Z
440
+ ---
441
+
442
+ # Schema
443
+
444
+ | Column | Type | Description |
445
+ |---------------|-----------|------------------------------|
446
+ | `order_id` | STRING | Unique order identifier. |
447
+ | `customer_id` | STRING | FK to [customers](/tables/customers.md). |
448
+ | `total_usd` | NUMERIC | Order total in USD. |
449
+
450
+ Part of the [sales dataset](/datasets/sales.md).
451
+ ```
okf_cli-0.1.0/PKG-INFO ADDED
@@ -0,0 +1,144 @@
1
+ Metadata-Version: 2.4
2
+ Name: okf-cli
3
+ Version: 0.1.0
4
+ Summary: Open Knowledge Format tooling
5
+ License: MIT License
6
+
7
+ Copyright (c) 2026 Dheerapat Tookkane
8
+
9
+ Permission is hereby granted, free of charge, to any person obtaining a copy
10
+ of this software and associated documentation files (the "Software"), to deal
11
+ in the Software without restriction, including without limitation the rights
12
+ to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
13
+ copies of the Software, and to permit persons to whom the Software is
14
+ furnished to do so, subject to the following conditions:
15
+
16
+ The above copyright notice and this permission notice shall be included in all
17
+ copies or substantial portions of the Software.
18
+
19
+ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
20
+ IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
21
+ FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
22
+ AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
23
+ LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
24
+ OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
25
+ SOFTWARE.
26
+ License-File: LICENSE
27
+ Requires-Python: >=3.13
28
+ Requires-Dist: typer>=0.15
29
+ Description-Content-Type: text/markdown
30
+
31
+ # okf-cli — Open Knowledge Format tooling
32
+
33
+ Converts plain markdown into [OKF](https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md)-conformant knowledge bundles. Domain experts write `# Title` then `> description` — `okf enrich` generates frontmatter, type, timestamps, and index files.
34
+
35
+ ## Quickstart
36
+
37
+ ```bash
38
+ uv sync
39
+ uv run okf example # output → bundled/
40
+ cat bundled/index.md
41
+ cat bundled/tables/orders.md
42
+ ```
43
+
44
+ ## Usage
45
+
46
+ ```
47
+ okf <input-dir> [output-dir] [--default-type <name>]
48
+ ```
49
+
50
+ | Argument | Description |
51
+ |---|---|
52
+ | `input-dir` | Directory of plain `.md` files |
53
+ | `output-dir` | Target directory (default: `bundled`) |
54
+ | `--default-type` | Type for root-level files (skip root files if omitted) |
55
+
56
+ ## Writing input files
57
+
58
+ Every `.md` file must start with:
59
+
60
+ ```markdown
61
+ # Title
62
+
63
+ > Description
64
+ > Second optional description line.
65
+ ```
66
+
67
+ Everything after the description block is free-form — preserved unchanged.
68
+
69
+ **Rules:**
70
+
71
+ | Rule | Why |
72
+ |---|---|
73
+ | First line must be `# Title` | Tool reads title here |
74
+ | Followed by `> Description` | Tool reads description here |
75
+ | Folder name = concept type | `tables/orders.md` → `type: "tables"` |
76
+ | Only `.md` files processed | Non-`.md` files ignored |
77
+ | Reserved names skipped: `index.md`, `log.md`, `README.md` | OKF spec reserves these |
78
+
79
+ **Violations:**
80
+
81
+ | Condition | Behavior |
82
+ |---|---|
83
+ | Line 1 not `# Title` | Error, stop |
84
+ | Empty title | Error, stop |
85
+ | No `> description` block | Error, stop |
86
+ | Root-level file without `--default-type` | Skip file, warn, continue |
87
+
88
+ Root files need `--default-type`. Otherwise put files in named folders.
89
+
90
+ See the [`example/`](example/) directory for a sample of how to structure files.
91
+
92
+ ## How it works
93
+
94
+ 1. Walk `input-dir` for `.md` files (skip reserved names)
95
+ 2. Extract `title` from `#`, `description` from `>`
96
+ 3. Set `type` from parent dir name, `timestamp` from file mtime
97
+ 4. Write concept files with YAML frontmatter
98
+ 5. Generate `index.md` per directory — `# Contents` for files, `# Directories` for subdirs (recursive)
99
+
100
+ ## Output
101
+
102
+ Each concept becomes a markdown file with YAML frontmatter:
103
+
104
+ ```yaml
105
+ ---
106
+ type: "tables"
107
+ title: "Customer Orders"
108
+ description: "One row per completed customer order across all channels."
109
+ timestamp: "2026-07-04T15:06:51+00:00"
110
+ ---
111
+
112
+ Original body preserved as-is.
113
+ ```
114
+
115
+ Every directory gets its own `index.md`:
116
+
117
+ ```markdown
118
+ # Contents
119
+
120
+ * [Customer Orders](orders.md) - One row per completed customer order across all channels.
121
+
122
+ # Directories
123
+
124
+ * [partitions](partitions/)
125
+ ```
126
+
127
+ ## OKF Conformance
128
+
129
+ Generated bundles conform to [OKF v0.1](OKF_SPEC.md) (§9):
130
+
131
+ - Every non-reserved `.md` has parseable YAML frontmatter with non-empty `type` ✓
132
+ - Reserved filenames follow spec structure ✓
133
+ - Consumers MUST tolerate missing optional fields, unknown types, broken links ✓
134
+
135
+ ## Project layout
136
+
137
+ ```
138
+ okf-cli
139
+ ├── OKF_SPEC.md # OKF specification
140
+ ├── pyproject.toml # uv-managed Python project
141
+ ├── src/okf/cli.py # Single-file CLI
142
+ ├── tests/test_cli.py # Tests
143
+ └── example/ # Sample input markdown
144
+ ```