T-JCML-augmented-convergence-audit

Status: closed/superseded · Impact: medium · Complexity: medium

Goal

The adoption tasks vendor augmented_books in working-as-is; the owner’s stated intent is to “share libraries and componentry as much as possible.” This task is the systematic sweep that finds the sharing opportunities the mechanical migration deliberately deferred, and turns each into a backlog entry. Analysis only — no code changes.

Today

Location	Role today
LIBRARIES.md	Registry of the monorepo’s shared libraries the migrated code should converge onto
packages/ts/	Post-adoption home of both ecosystems’ packages, side by side
packages/rust/	dir-aspect, platform-core, plus the vendored augmented-common / frontmatter-validator
docs/planning/analysis/	Home of prior analysis documents; the deliverable lands here
docs/planning/backlog/	Where each actionable verdict is captured via sdlc backlog create

Proposed

One analysis document with a verdict per axis, plus one backlog entry per actionable verdict. The axes:

Migrated thing	Existing counterpart	Question
@augmented/render (markdown + wiki-links)	@sksizer/obsidian-astro, vendored markdown-contract	One markdown/wiki-link substrate?
frontmatter-validator (Rust CLI)	markdown-contract (TS)	Keep, fold, or retire
@augmented/entity + context + hierarchy	@determined/platform, the ontogen/ontological direction	Entity-model overlap
@augmented/logging, @augmented/utils	Monorepo idioms	Adopt repo-wide, fold, or retire
Vue components across migrated apps (desktop src-frontend, learn_web layers, demos)	@determined/ui, @sksizer/panes	Extractable shared componentry
Vault handling in migrated code	@sksizer/vault-path, dir-aspect	Path/config unification
@augmented/@augment scopes	@sksizer scope	Rescope or keep; one scope for shared packages

Approach

1. Per axis: inventory the migrated side (exports, call sites, LOC) and the existing counterpart’s surface. Cite files, not impressions.
2. Issue a verdict per axis: share (port consumers onto the existing lib), fold (merge capabilities into one package), keep (genuinely distinct), or retire (dead weight). One or two sentences of rationale each.
3. Write the analysis doc at docs/planning/analysis/augmented-convergence.md: one section per axis — inventory table, verdict, rationale.
4. For each share/fold/retire verdict, capture a backlog entry via sdlc backlog create and list the minted B-IDs in the doc.
5. Keep verdict thresholds honest: a share verdict needs a named consumer list and a named target API, not vibes.

Files to touch

Location	Kind	Change
docs/planning/analysis/augmented-convergence.md	new	The audit document: per-axis inventory, verdicts, backlog IDs
docs/planning/backlog/	modify	New backlog entries, one per actionable verdict (via sdlc backlog create)

Acceptance criteria

• AC-1: The analysis doc exists and covers all seven axes, each with an inventory table and an explicit verdict.
• AC-2: Every share/fold/retire verdict has a corresponding backlog entry, and the doc lists the B-IDs.
• AC-3: No source-code changes in the PR — analysis and backlog files only.

Out of scope

• Executing any convergence (each verdict becomes its own backlog entry → task).
• The obsidian-bases dedup — already decided and specced as T-NLKF.

Dependencies

• All adoption tasks: T-LVLY, T-F0B2, T-JV2A, T-6C0Z, T-KTGF, T-LAKY, T-UPV1 — the audit reads the code in-tree.

Discovery context

• The owner’s framing for the whole adoption (2026-07-18): “I want to share libraries and componentry as much as possible between them.”

Post-mortem

Captured by /sdlc:task-work on 2026-07-19. PR: pending.

Acceptance criteria coverage

TBD — filled at Step 8.

What worked

TBD — filled at Step 8.

Friction and automation gaps

TBD — filled at Step 8.

Depends on

T-LVLY, T-F0B2, T-JV2A, T-6C0Z, T-KTGF, T-LAKY, T-UPV1

---

← Back to Tasks