feat(aligned-onboarding): Knoweth organize part (global+tags today, family lanes as forward path) - #175
Conversation
…onfig, standard specs, front-matter, repair, validation, gotchas (option B, consistent)
|
Expanded the Knoweth organize doc from a thin "organize step" into a full operational spec, and made the lane model consistent throughout (option B: everything in Added sections: save routing + refresh, how to decide the lanes/config (tags + naming decoder, family-lane candidates for later), the Standard-spec format and the three specs, the front-matter schema, the existing-org repair checklist, the validation / retrieval smoke test, gotchas, a worked example, and the standard-vs-brand-decided framing. Dropped only the repo-meta "packaging" notes (they live in this PR description, not the staged doc). Still open (unchanged): the harness dependency to layer configured lanes (fits PDEC-9225), the |
…t-in-Knoweth, no-Knoweth-aware, user/workspace lane scenarios, org-type adaptation, standard-spec detail, maintenance section
|
Updated to v1.0 (final, not a draft) and marked ready. Changes from the round of review:
On activation (the double-check): aligned-onboarding has no auto-activation, it triggers when a person runs the package/README (same as every other part). This file is staged via |
|
Applied the "now" batch from review:
Still open and not in this PR: guaranteed activation via an orchestrator or the schema-v1 |
|
|
||
| ## 12. Rollout, triggering, and how it stays consistent | ||
| - **The package ships to the GitHub repo and installs on every VM, but installing does not act.** A trigger is needed: an SSH conversation per VM that says "use this package / do the readme," which runs the setup. New orgs onboard this way; existing orgs get a manual cleanup pass. | ||
| - **VoC auto-installs on connect** (the connect-time dispatch), so a connected platform pulls without a manual trigger; secrets-path platforms use the manual `package intent add-integration` route. |
There was a problem hiding this comment.
VoC doesn't auto install on connect anymore, right?
| - `[[lane_assignments]]` override the lane for a root-relative path glob, last match wins (e.g. `css-2026/**` -> `project:css-2026`). This is how a project or business lane is carved out of a tree. | ||
| - `[policy]` with `default_read_lanes` and `[[policy.lane_grants]]` keyed by `user_id` and/or `project_id` (each `read = [lanes...]`, optional `write`) is the ACL: it decides which layered lanes a request can read. User/team separation lives here (grant `user:alice` only to `user_id = "alice"`). | ||
| - `[embeddings]`, `[hybrid]`, `[resolver]` tune the search channels (checked-in default is guarded OpenAI hybrid: lexical + graph + adaptive dense, fused with RRF). | ||
| The lane count matters because every authorized lane is scored per query; keep the set small (verify the cap). **Caveat: today only `global`, `user:<userId>`, and `project:<workspaceId>` are in the requested read set, so `[[lane_assignments]]` that create family/initiative lanes are forward-path only, using them now hides content.** Keep content in `global` plus tags until the harness layers configured lanes. The skeleton plus the front-matter attributes are the content the config's roots/assignments are generated from. Note the repo is migrating to the OS package format (`runneth-package.json` schema-v1, targets under `agent_brain`/`agent_skills`/`agent_tools`/`agent_apps`); the Knoweth package registers there. |
| --- | ||
|
|
||
| ## 5. Front-matter (findability and provenance, not a filter) | ||
| Front-matter is **not a Knoweth query filter.** Retrieval runs on lane (today `global`, `user:<userId>`, and the workspace) plus lexical/dense search over the text. The header earns its place for four things only: lexical findability (facet words become searchable text), provenance (`sources` cite the exact raw file), chunk-standalone context (a chunk is retrieved without its neighbors), and agent-side filtering of returned files. Keep it lean and do not restate what the path or config already encode. VoC raw file (one per item), aligned to the installer package's unified record: |
There was a problem hiding this comment.
this tells runneth to add front-matter to VoC files, but the shipped voc template doesn't use front-matter at all.
metadata lives in the collapsed YAML block at the bottom (front-matter rendered badly in the file viewer, check out Harry's okendo files, so we dropped it).
so these two docs disagree about the same files. can this section just point at the voc template and use that metadata block as the tag source?
we can also go back to front matter. It is a UI thing, but maybe we're less concerned.
| voc/<integration>/ticket-<id>.md # (no reviews/ or tickets/ subfolders) | ||
| voc/meta-ads/comment-<id>.md # meta ad comments are VoC | ||
| voc/reddit/post-<id>.md | ||
| voc/<integration>/<integration>-context.md # compiled: segments, personas, keywords, quotes |
There was a problem hiding this comment.
this puts a summary file in the folder where the voc sync writes raw items - the skill uses that folder for its "empty → backfill" and "newest item date" checks, so a non-item file can trip both. move it one level up?
|
I left direct inline comments for a few of these already All in runneth-apps unless noted:
|
…record, no per-creative brain files - Rewrite the Creative Attribution playbook as the creative-content-layer contract: what Cacheth holds per creative, the query paths (Knoweth injection first, then the motion cache CLI), and the naming decode - all local, no API calls, nothing written to the brain - Fold the naming decode into account-context.md Field 4 (no separate taxonomy file); Field 4 starts from the Step 1 provisional table - Reframe per-creative-file rules from prohibition to ownership: person-requested snapshots allowed, sweep asks before archiving - Validation (v1.3) gates on cache coverage instead of files and adds the show-the-work loop rule - Upgrade the Knoweth answer standard: read the naming decode before name filters, route structural vs creative questions by signal, frame performance + VoC as one system, state filter/signal/unconfirmed on analytical answers - Stage the Cacheth command reference beside the Data-Query Guide; reconcile all cache command syntax against it Co-authored-by: Cursor <cursoragent@cursor.com>
1799273
into
eric/aligned-onboarding-v2-meta-package
3 participants
Add the Knoweth "organize the brain" part to aligned-onboarding
Stacked on #172 (base is that PR's branch), so this shows only the Knoweth additions. Merge after / into #172.
What this adds
aligned-onboarding/knoweth/knoweth-organize-onboarding-package.md— the cross-cutting Knoweth part, in the same house style as the meta parts (version, one-line model, activation with two sentinel guard blocks, hard-gate prerequisites, scope, persistence, honesty section, changelog).install-config.json— registers the file (v2.2.0) so it stages to/agent/brain/aligned-onboarding/.README.md— adds the "Organize with Knoweth (after the questions are answered)" step to the run order.The part in one line
After the account questions are answered and content has landed, organize the brain so retrieval stays tight, then hold it with a standing save + maintenance contract (the
runneth:knoweth-organizeandrunneth:knoweth-brainguard blocks merged into user.md).Key design decision (grounded in the harness code)
The harness requests exactly
[user:<userId>, project:<workspaceId>, global], andprojectis the Motion workspace. So today: keep all shared content in thegloballane and slice it with tags + a naming decoder;user:lanes for isolation; the workspace project lane is automatic. Do not carve data-source-family or initiative lanes on a live VM — they are not queried yet and the content would go dark. The family-lane scheme is documented as a forward path gated on a harness change (option B), not shipped.Open items for review
runneth-package.jsonschema-v1; aligned-onboarding usesinstall-config.json. Worth reconciling for the OS-package migration.