Prompt 1: Replace your model of this system

Paste the text below to the Manus agent, with this pack attached or unzipped in its working directory.

---

You previously produced 23 video tutorials for me. They were grounded in a picture of my working system that was wrong, so most of the instructions in them cannot be followed. I have sent you a context pack that replaces that picture. This task is ingestion. Do not produce tutorials yet.

1. Read these first, and treat them as authoritative

Read them in this order, in full, before you write anything:

1. GROUND-TRUTH-2026-08-01.md. The verified condition of the system as of 2026-08-01: what runs, what is specified and unbuilt, which repositories and tools are real.
2. TECHNICAL-BRIEF.md. What every named component does and how they compose.
3. DEV-SETUP-STATE.md. GitHub, Jira, the monorepo, the gates, the roles, and the order of work, with planned things labelled as planned.
4. shuriq-okf-profile.md. The Open Knowledge Format profile: type vocabulary, extension keys, guards, conformance rules.
5. CONCEPT-SPACE-READER.md and the posts in blog-posts/. How we argue and how we write.
6. The corrected tutorials in tutorials/. Worked examples of correct grounding.

Where any of these disagrees with something you already believe about my system, the document wins.

Where two documents in the pack disagree with each other, do not resolve it silently and do not assume the summary document is right. Prefer whichever document names a primary check and the date it was made, such as a command that was run, an API that was queried, or a file that was counted. A document that states a number without saying how it was obtained loses to one that shows the check. Report every conflict you find, with both readings and the reason you preferred one, and flag any you cannot settle that way.

2. Discard your prior model of the stack

You read the starred and forked repositories on the jonnydubowsky GitHub account and treated them as my working system. They are reference material and abandoned experiments. Across your 23 tutorials you named graphify 97 times, knowledge-base-server-demo 78 times, obsidian-mcp 61 times, SimpleMem 46 times, mempalace 42 times, and NexAU 24 times.

None of those six is part of the working system. Delete them from your model now. Do not name any of them again in anything you write for me, in any role, including as an example, an analogy, or an alternative. Any sentence grounded in one of them is wrong by construction.

The one-line replacement: the work runs out of an Obsidian vault driven by Claude Code, with skills, agent specifications, and Bases dashboards, plus a small number of Python and Ruby tools inside that vault and Cloudflare Pages and Workers for every deploy. It does not run out of a conventional application repository.

3. Understand the OKF bundle in this pack

The pack includes an OKF bundle. Read it correctly.

Open Knowledge Format is a specification from Google Cloud, version 0.1, released 2026-06-12. A bundle is a folder of Markdown files. Each file is one concept. Each concept carries YAML frontmatter whose only hard requirement is a non-empty type. Everything else, including title, slug, description, resource, tags, and timestamp, is recommended rather than required.

Four properties decide how you consume it:

• Links carry no edge type. OKF has no typed relationships. Relationship meaning lives in the prose body. When you need to know how two concepts relate, read the bodies. Do not infer a typed edge and do not assert one.
• index.md and log.md are reserved names at the bundle root and in each subfolder. index.md is the generated listing you read first to decide which concepts to open. log.md is a bundle log. A source document actually named INDEX.md is written out as INDEX__doc.md so it cannot collide.
• The bundle is a Layer 2 projection. It is deliberately poorer than the internal store it came from. It carries no typed edges, no scoring internals, and no second-order dynamics. That is by design, and it is a policy decision rather than an oversight.
• resource: resolves inside this pack. Each concept's resource: is a path relative to the bundle root, such as ./tutorials/118-why-agentic-systems-need-ontologies.md. Open it directly. Concept bodies here carry the full document rather than a stub, because you cannot reach my vault. The companion key shuriq_source_path records where the document lives in my vault, for provenance and for mirroring your output back. Treat shuriq_source_path as a label and never as something to fetch.

4. Keep working in OKF

When you produce new knowledge for me, emit it as OKF concept files so I can mirror your output straight back into the vault without transcription.

Rules for anything you emit:

• One concept per Markdown file. Filename is the slug: lowercase, hyphens, no spaces. OKF warns on filenames with spaces because they are hard to link.
• type must come from the vocabulary in shuriq-okf-profile.md. The values in use include GapReport, StrategyDoc, ContentBrief, SessionReport, MetaAnalysis, PostCallAnalysis, EngagementCycle, BrandProfile, Template, Playbook, Index, Transcript, Meeting, KnowledgeGraph, Roadmap, Naming, IntakePackage, FAQ, Editorial, OntologyClass, Log, and Document as the fallback. If nothing fits, use Document and say in your reply which new type you would propose. Never invent a type silently.
• Set title, slug, description, and tags on every concept. Set timestamp to a full ISO date such as 2026-08-01, or omit the field. Never write unknown; the OKF validator rejects it.
• Use only these extension keys, which are the export-safe list: shuriq_source_path, shuriq_source_type, shuriq_source_sha256, shuriq_layer, shuriq_okf_generated, shuriq_rea_type, shuriq_bmc_cell, shuriq_bmc_variant, shuriq_bundle_role. Set shuriq_layer: 2 on everything you produce.
• Never write a key matching sbpi* or dkr_*. Those are internal-only and you have no data that belongs in them.
• Body shape: # Title, then ## Intent saying what the concept exists to do, then a short paragraph saying plainly what it is, then ## Sources listing where it came from. Keep the body a projection. Do not narrate typed relationships in it.

Deliver a set of concepts as a folder with an index.md listing every concept with a one-line purpose.

5. Writing rules, which are checked by a program

A deterministic gate reads the output and exits non-zero on a violation, so these are pass or fail rather than preferences.

• Zero em-dashes. Use a comma or a period. The gate matches the character itself and both of its HTML entity spellings, the named one and the numeric one, so encoding it does not get it past the check.
• Full ISO dates only, such as 2026-07-28. Never "July 2026" and never "Q3 2026".
• No inversion rhetoric of the "not X, but Y" shape. Lead with the affirmative claim.
• No unanchored metaphor and no consulting abstraction a reader cannot point at. The exact list ships with this pack as banned-terms.txt, one rule per line in the form TIER|||regex|||hint. A BLOCK tier stops the work; a WARN tier asks for a look. The words are not repeated here, because writing them out would trip the checker on this document. Load that file, apply it to everything you produce, and prefer "core", "recommendation", and "action" as replacements.
• The reason for the list is measurable rather than stylistic. A language-model reviewer read a document as clean while one banned word rendered 56 times in it. The program counts; a reader does not.
• One thought per sentence. Say each point once. Do not restate a point in a later section.
• No self-reference. Never describe your own document's sections and never narrate what the document is doing.
• No cryptic internal code without expanding it on first use.

Self-check your output against these before you return it, and state in your reply that you did.

6. Ask before inventing

If a path, repository, ticket, command, URL, or tool is not in this pack, it does not exist. That is the rule that produced the failure I am correcting.

When you need something the pack does not contain, say exactly what is missing and stop. Do not fill the gap with a plausible name, do not generalise from a public project with a similar purpose, and do not carry a detail forward from your earlier tutorials.

Two things you will want and will not find, so that you do not guess at them:

• There is no Jira instance. No site, no project key, no epic identifiers, no board. A design for one is written and nothing has been created.
• The GitHub organization shuriq-lab exists and contains zero repositories. No repository name has been chosen.

7. What to return for this task

Return, in plain Markdown:

1. A statement that you have discarded the six repositories, listing them by name.
2. A list of the components of the real system you now hold, with one line each on what each one does and whether it runs today or is specified and unbuilt.
3. The three largest corrections between your prior model and the pack.
4. Every question you have where the pack left you short, with the specific slug or path you would need.

Do not write tutorials in this task. The tutorial instruction arrives separately.