explain spec: review rosetta's steering/positioning findings (B-0013) before locking the design

[mobileskyfi]

Context

rosetta just recorded a positioning pass on steering vs skills vs rosetta vs centrs now that manual.mikrotik.com is machine-readable (llms.txt, per-page .md). When #90 gets its per-command design doc (commands/explain/), that spec should review these findings so the rosetta/centrs explain boundary is deliberate rather than accidental:

• Boundary lean (rosetta side): rosetta owns static, docs/schema-grounded explanation (tier-1, never touches a router); centrs owns canonicalization and anything device-aware, per JG-11: explain command — LSP-like rich command analysis (centrs as canonicalizer owner) #90's "centrs as canonicalizer/explain owner". centrs should consume rosetta (DB or library) for doc/version enrichment rather than duplicate retrieval; rosetta will not grow validate/run.
• Ladder framing: prompt steering → skill → rosetta → centrs, each rung advertising the next. Only the centrs run tier closes the removed-capability / silent-default traps (bench-routeros-tools live pilots — the vendordoc-steer condition cites real manual pages reliably and still misses every device-truth trap).
• Skill-as-distribution convergence: rosetta is adding a one-shot CLI query mode (bunx @tikoci/rosetta search "…" --json, rosetta T-0032) so a plain SKILL.md can drive it with zero MCP config — the same pattern Agent onboarding: repo-local SKILL.md served via Pages + copy-prompt button (browserbase pattern) #150 pilots from the onboarding side. If both work, Agent onboarding: repo-local SKILL.md served via Pages + copy-prompt button (browserbase pattern) #150's "trilogy meta-skill" idea is the convergence point, and explain enrichment via a shelled-out rosetta one-shot (no MCP dependency) becomes a cheap integration option worth considering in the spec.

What to review (in tikoci/rosetta, landing with its next push)

• briefings/B-0013-steering-skills-rosetta-positioning.md — the full argument + grounding (bench numbers, llms.txt cost measurements)
• briefings/B-0012-docusaurus-manual-migration.md — manual.mikrotik.com machine-readable facts, site-search internals (no server search API; client-side lunr; slash-splitting tokenizer)
• DESIGN.md → "Rosetta vs prompt steering and skills"

Refs

• JG-11: explain command — LSP-like rich command analysis (centrs as canonicalizer owner) #90 (explain owner — this is input to its design doc, not new scope)
• Agent onboarding: repo-local SKILL.md served via Pages + copy-prompt button (browserbase pattern) #150 (SKILL.md onboarding pilot; convergence noted above)
• MikroTik forum thread 270916 (steering recommendations + post docs(matrix): compress devices cell prose to status + pointer #20 site-search research)

[mobileskyfi]

Reviewed for the explain spec (PR #184). B-0012/B-0013 and the rosetta-alignment doc were read in full and the boundary is adopted verbatim in commands/explain/README.md:

• rosetta owns static, docs-grounded explanation (prose, URLs, version history) and never grows validate/run; centrs owns canonicalization + anything device-aware; "live wins for structure/existence, static wins only for the prose/history it uniquely carries" is stated as the merge rule.
• rosetta enrichment is an explicitly optional --docs facet; the integration mechanism (vendored docs-links JSON vs the T-0032 one-shot bunx @tikoci/rosetta … --json shell-out vs optional local ros-help.db) is open question 4 in the spec — the T-0032 outcome is the natural trigger for deciding it.
• The ladder framing survives in the spec's grounding section: explain is the rung-3 knowledge tier, and its results stay honest about what only run proves (runtimeAcceptance: "not-proven").

Since the ask here was "review before locking the design" and the design is deliberately not locked yet (the spec queues the design rounds on #90), suggest keeping this open until open question 4 (rosetta mechanism) is decided, then closing with that decision.