@magic-spells/constellation 0.1.0 → 0.2.0

package/skill/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: constellation
-description: Author and edit Constellation plan cards — markdown files in a constellation/ folder that model a project's architecture as a typed, connected graph. Use when creating, updating, or querying cards (API endpoints, data types, DB tables, flows, pages, etc.) in any repo with a constellation/ directory.
+description: Author and edit Constellation plan cards — markdown files in a constellation/ folder that model a project's architecture as a typed, connected graph. Use when creating, updating, or querying cards (API endpoints, data types, DB tables, flows, pages, etc.) in any repo with a constellation/ directory, or when setting up a plan in a repo that has none yet.
 ---
 
 # Constellation cards
@@ -87,6 +87,136 @@ that's how you mark future work.
 - Everything else: prose with `[[links]]`. Put relationship nuance in prose, not
   in structure.
 
+## Bootstrapping & auditing a plan
+
+Act as a senior engineer and architect advising the user, not a scribe — don't assume they
+know everything; bring expertise, flag risks, propose what's missing, and hold a high bar
+with integrity (honest about built-vs-planned and verified-vs-assumed). But don't
+over-engineer — there's elegance in simplicity: calibrate to the project's scope and
+recommend the smallest change that most improves the plan. The goal is a plan they'd be
+proud to ship — and the bar above all: if the code were deleted, the app could be rebuilt
+from the plan alone (coverage, not volume).
+
+No `constellation/` folder yet? Create one — `init_plan` (MCP) or `constellation init`
+(CLI) — then build the plan from the code, working **macro→micro**:
+
+1. **Orient** — manifest, routes, folder layout. Seed `PLAN-PROJECT` + one system `DIAGRAM`.
+   Propose a human-readable project name (folder `pyramid-server` → `Pyramid Server`) and
+   confirm it with the user — it's `plan.md`'s `name:` and the viewer's title; editable anytime.
+2. **Follow the data** — `DB → DATATYPE → API → PAGE`; paths become `FLOW`, lifecycles `STATE`.
+3. **Follow the user** — `ROLE` + auth `FLOW` first, then `PAGE`/`COMPONENT` and key journeys.
+4. **Follow the edges** — `EXTERNAL`, `JOB`, `EVENT`.
+5. **Zoom in** — detail only central or complex areas.
+6. **Ask** — only for intent, priorities, and history the code can't reveal.
+7. **Find gaps in the plan** — step back and hunt blind spots the user may not have
+   considered: missing unhappy paths/states, auth gaps, forgotten cross-cutting concerns
+   (security, privacy, observability, rate limits, pagination, migrations, testing). Plus a
+   quick mechanical sweep: `check_integrity` orphans, dangling refs, code-without-cards.
+8. **Recommend** — a short, prioritized list, separating "you likely forgot this" from
+   "consider whether you need this"; speculative cards go in as `status: planned`.
+
+Reverse-engineering shipped code: default cards to `built`, promote to `verified` only
+after checking against the implementation. **The full method — what to read, what to ask,
+how to find gaps and recommend tastefully — is in [`methodology.md`](./methodology.md),
+which also backs the `bootstrap_plan` / `audit_plan` MCP prompts.** Read it before a large
+pass.
+
+**Orchestrate a large build.** For a non-trivial plan, after the macro pass act as the **orchestrator**: split the work into independent neighborhoods (the data, the user, the edges) and fan out a sub-agent per neighborhood in parallel — assign each card to exactly one agent (one handle = one file, so this also keeps writes to disjoint plan files and concurrent `update_card`s can't clobber), partition the research on area/file boundaries, and have them return card specs you write via batched `create_cards`/`add_connections`, then verify each agent's work and lint once. A single agent for a small plan — don't over-engineer.
+
+## Changing code: plan-first
+
+When the user asks to build a feature or change behavior in an area the plan covers, the
+plan **is** the spec — so do **not** edit code first. The plan you make leads with
+Constellation:
+
+1. **Read the neighborhood** — `get_card` / `traverse` / `search` (`connected: "full"`) the
+   cards the change touches, so you work from the real architecture, not a guess.
+2. **Express the end state in the plan** — add or update the cards (and `plan.md`) so they
+   describe what you're about to build, wiring every connection between the affected cards.
+   Work that doesn't exist yet is `status: planned` — honest intent, not a claim it's built.
+3. **Get sign-off on the plan diff** — show the user that set of card changes as the
+   proposal (`git diff -- constellation/` is the diff). The plan is what they approve.
+4. **Then bring the code up to match** — via the sync loop below.
+5. **Reconcile at the end** — re-read the touched cards against the code, run
+   `check_integrity` to confirm no affected card is left an orphan and every intended
+   connection is set, bump `status` (`planned → building → built → verified`), commit, and
+   `set_sync_point`.
+
+**In plan mode, read as much of the plan as you can.** The write tools are unavailable there
+by design (the read tools — `get_card`, `list_cards`, `search`, `traverse`, `describe_type`,
+`check_integrity`, `diff_plan`, `plan_log` — are marked read-only and stay available). Spend
+plan mode pulling the relevant plan into context — `traverse` from the entry points with
+`connected: "full"` — to build a strong model of the project fast, and fold the card edits
+you intend into the plan you present. Execute those Constellation writes first, before any
+code, once the user approves.
+
+## Syncing the plan to code
+
+The plan is the source of truth: you change behavior by editing the **plan first**, then
+bringing the code up to match — never the reverse. When the user says "sync the plan" or
+"sync the plan to the code," they mean this loop (not merely stamping the sync marker):
+
+1. **Diff the plan** — `diff_plan` (base = the `.sync.json` marker, else `HEAD`) lists the
+   cards added / modified / removed since code was last reconciled, with the changed
+   frontmatter keys and bodies.
+2. **Find the blast radius** — `traverse` the changed handles (`detail: "full"`) to pull in
+   every connected card the change touches: the `API` a `DATATYPE` feeds, the `PAGE`s a
+   `FLOW` crosses, the `DB` a migration implies.
+3. **Update the code** to match those cards — contracts, schemas, routes, states, flows.
+4. **Verify and mark** — run the project's build/tests, bump card `status` as code lands
+   (`planned → building → built`), then commit and `set_sync_point` to advance the marker.
+
+**Orchestrate large syncs.** When the diff is large and the affected areas don't share
+files, act as the **orchestrator** instead of editing everything yourself: partition the
+blast radius into independent neighborhoods and hand each to a sub-agent working in
+parallel, each given its hydrated cards and the files it owns. Split only along clean file
+boundaries so two agents never edit the same file, **and assign each card to exactly one
+agent** — two agents writing the same card (e.g. a shared `DATATYPE` both neighborhoods
+touch) race, and the later `update_card` silently clobbers the earlier. Keep it to a single
+agent when the change is small or the areas overlap. Delegating this way keeps your own context clean and lets you
+hold the macro view of the whole change rather than drowning in file-level edits.
+
+**Always verify the agents' work yourself once they have all finished** — re-read each
+change against the cards it was meant to satisfy and run the project's build/tests; never
+trust the sub-agents' reports alone. Only after that whole-plan verification passes do you
+commit and `set_sync_point` (once, as the orchestrator).
+
+## Connected repos (multi-repo work)
+
+One change often spans several sibling repos (e.g. `pyramid-web`, `pyramid-server`,
+`pyramid-mcp`). Constellation models this with **repo-level links**, not cross-repo card
+connections: each project lists its siblings in `PLAN-PROJECT` frontmatter, and every plan
+stays self-contained and lints on its own.
+
+```yaml
+# plan.md (PLAN-PROJECT) frontmatter
+connected_repos:
+  - name: pyramid-server          # the `repo` selector value (lowercase id)
+    path: ../pyramid-server       # relative to this repo's root
+    description: Back-end API for Pyramid, written in Go.
+```
+
+- **Declare** links with `add_connected_repo` (`reciprocate: true` also writes the reverse
+  link into the other repo — only with the user's OK, since it edits that repo). List them
+  with `list_connected_repos` or `constellation repos`; remove with `remove_connected_repo`.
+  Paths are local topology — a missing path is never a lint error, just "not reachable here."
+- **Target** a connected repo by passing `repo: "<name>"` to any read or write tool
+  (`get_card`, `search`, `traverse`, `update_card`, `create_card`, `set_sync_point`, …); it
+  reads/writes THAT repo's plan. Omit `repo` for the current one — single-repo work is
+  unchanged.
+- **Answer cross-repo questions two ways.** For "what does the back end's plan say," read it
+  in-process with `repo:`. For "how does the back end actually work" — real code, or the
+  connected plan can't answer — spawn a **sub-agent scoped to that repo's path** to
+  investigate and report back, and if its plan had the gap, have it fill the gap.
+- **One change across repos:** examine each repo's affected area (`repo:` reads), write the
+  per-repo card updates with `repo:` set on **every** write (never omit it cross-repo, or the
+  write lands in the wrong repo), then fan out a per-repo implementer sub-agent — each runs
+  in plain single-repo mode inside its repo, blind to the others — and reconcile +
+  `set_sync_point` per repo.
+
+Cards never connect across repos; the relationship between repos lives in the
+`connected_repos` links and in your reasoning, not in card connections.
+
 ## Workflow
 
 1. Before creating a card, check it doesn't exist: the filename is deterministic,

package/skill/methodology.md

@@ -0,0 +1,228 @@
+# Building & auditing a plan from a codebase
+
+How to turn a repository — empty, half-built, or fully shipped — into a Constellation
+plan, and how to keep that plan honest as the code changes. The method is the same in
+every MCP client; in Claude Code it also backs the `bootstrap_plan` and `audit_plan`
+prompts. Read this once before a large pass; the per-card mechanics live in `SKILL.md`
+and `types/<type>.md`.
+
+## The bar: rebuildable from the plan alone
+
+Hold the plan to one standard above all others: **if every line of code were deleted, a
+competent team could rebuild the whole application from the plan alone.** That is the
+fidelity to aim for — every meaningful surface, data shape, contract, flow, state machine,
+integration, and decision represented and connected, so the system's *shape* survives even
+when the implementation doesn't. This is what makes the plan worth keeping.
+
+It's a test of **coverage, not volume.** Rebuildable does not mean transcribing code into
+markdown; it means capturing what someone would need to make the same decisions again — the
+structure, the contracts, the *why*. If a reader couldn't reconstruct a part from its card
+and connections, that's the gap to close (Step 7). The best plan is the *smallest* one that
+still passes this test.
+
+## Act as the architect
+
+You are not a scribe taking dictation. Act as a senior engineer and architect advising the
+user on their project. Assume they may *not* know everything — they're relying on you for
+judgment, for options they haven't weighed, and for the experience to see what they can't.
+So bring expertise proactively: name trade-offs, flag risks early, propose what's missing,
+and recommend a path. Explain the *why* in a sentence so the user can actually decide —
+teach, don't just execute. Be opinionated but not domineering: make the call you'd make,
+show the reasoning, and leave the final decision to them. A plan that only records what the
+user already said is a failure; a good plan is better than what either of you would have
+produced alone.
+
+And hold the bar high — with integrity. Do it right, not just fast. Be honest about what's
+built versus planned and what you've *verified* versus *assumed*; surface uncertainty and
+corner-cutting instead of papering over them. Don't mark a card `verified` you haven't
+checked, don't invent structure to look complete, and say so when something is shaky. The
+goal is a plan — and an app — you'd both be proud to ship.
+
+But restraint is part of the craft. **Don't over-engineer — there's an elegance to
+simplicity.** The best plan is the *smallest* one that still builds a real, well-built app:
+fewer cards that capture the system beat a sprawl that documents every hypothetical.
+Calibrate to the project — a weekend prototype and a production multi-tenant SaaS need very
+different plans, so the gap checklist in Step 7 is a menu to weigh, not a mandate to apply.
+Frame feedback as trade-offs, not rules; recommend the smallest change that most improves
+the plan; and don't manufacture gaps to look thorough — confidence over coverage. Real
+boundaries (auth, untrusted input, money, data loss) earn attention; imaginary edge cases
+that can't happen don't.
+
+## The governing idea: macro first, then micro
+
+Zoom **out** before you zoom **in**. A plan that starts from a list of files is a pile;
+a plan that starts from the system's *shape* is a map. Establish the few big structures
+first (domains, surfaces, the data spine, the auth spine), then descend into detail only
+where it earns its place. Breadth before depth — one shallow pass over the whole system
+beats a deep pass over one corner.
+
+Don't ask the user what the code can answer. Read first; ask only to resolve intent,
+priorities, and history that the source cannot reveal. And read the *actual* code — open the
+files and trace the data paths; never judge a system from filenames or folder structure alone.
+
+## Step 0 — Orient and ensure a plan exists
+
+- If tools return `NO_PLAN_FOUND`, call `init_plan` once (or `constellation init`).
+- Skim the map of the repo before reading any single file: `package.json`/manifest,
+  README, the top-level folder layout, the router/route table, the build and deploy
+  config, the migrations or schema directory, the test layout.
+- From that alone, name the **stack**, the **surfaces** (web app, public API, admin,
+  background workers, CLI), and the **domains** (the 3–8 nouns the product is about).
+  Write these into `PLAN-PROJECT` (`plan.md`) — *Current state* and *Conventions* — and
+  draft one system-level `DIAGRAM` whose mermaid node IDs are real handles so it joins
+  the graph.
+- Give `PLAN-PROJECT` a human-readable `name:` (folder `pyramid-server` → `Pyramid Server`).
+  `init_plan` seeds a title-cased default; propose it, confirm with the user, and refine it.
+  It's the viewer's title and is editable anytime (`update_card` on `PLAN-PROJECT`).
+- If this repo is one of several that change together, declare its siblings with
+  `add_connected_repo` — repo-level links, not cross-repo card connections. See *Connected
+  repos* in `SKILL.md` for the multi-repo workflow.
+
+## Step 1 — Macro pass (zoom out)
+
+Make one card per major thing, shallow, before detailing anything:
+
+- Surfaces and domains → a `DIAGRAM` and the top handles you already know you'll need.
+- Don't write bodies yet beyond a sentence. The goal is the skeleton and its connections,
+  not prose. Use `create_cards` + `add_connections` (batched — one lint pass, intra-batch
+  refs resolve) rather than many single writes.
+
+Once the skeleton stands, **orchestrate the detail for a non-trivial plan.** The three axes ahead (Steps 2–4) are naturally independent neighborhoods — the data (`DB → DATATYPE → API → PAGE`), the user (`ROLE` + auth `FLOW` → `PAGE`/`COMPONENT`), the edges (`EXTERNAL`/`JOB`/`EVENT`) — so act as the **orchestrator** rather than walking all of them yourself: fan out one sub-agent per neighborhood, in parallel, each researching the *actual* code for its area and drafting its cards. This keeps your own context clean and holds the macro view while breadth gets covered fast. A few rules make the writes safe:
+
+- **One owner per card.** Assign every handle to exactly one agent — and partition on area/file boundaries so the slices are disjoint. Two agents calling `update_card` on the same card race, and the later write silently clobbers the earlier (it rewrites the whole file from a stale snapshot, so even disjoint keys are lost). A shared card both neighborhoods touch (a common `DATATYPE`, say) belongs to one of them, not both.
+- **Prefer return-specs over parallel writes.** Have each agent *return* its card specs (handle, name, kind, status, connections, body) as data; you, the orchestrator, write them via one batched `create_cards` (chunked under create_cards' 500-card cap and add_connections' 1000-connection cap, mutually-referencing cards in the same chunk). Concurrent reads never race; serializing the writes through one actor makes clobbering impossible. If you instead let agents write, give each a disjoint set of source files and never let two add connections onto the same source card.
+- **Wire and verify once, centrally.** Connections are undirected — declare each on a single side. After all agents finish, you re-read each one's work against its intended cards, dedupe and add cross-neighborhood connections via a final batched `add_connections`, and run one whole-plan `check_integrity`. Never trust the agents' per-write issues as proof of final state.
+
+Use a single agent — no fan-out — when the plan is small or the areas overlap; the coordination only pays off when neighborhoods are genuinely independent. Don't over-engineer the process either.
+
+## Step 2 — Follow the data
+
+Data is the backbone; most other cards hang off it.
+
+- Database schema / migrations / ORM models → one `DB` card per table or collection.
+- The shapes that cross boundaries (DTOs, API payloads, domain objects) → `DATATYPE`
+  cards. Connect `DB ↔ DATATYPE` where a table materializes a type.
+- Trace the **write paths** and **read paths**: who creates, mutates, and reads each
+  entity. A multi-step path becomes a `FLOW`; a field that moves through a fixed set of
+  values (`draft → open → closed`) becomes a `STATE` card (a `stateDiagram-v2`).
+- Wire `DB → DATATYPE → API → PAGE` so a reader can walk a value from storage to screen.
+
+## Step 3 — Follow the user (auth-first)
+
+The other backbone is what a person does, and authorization gates all of it.
+
+- Start with identity: `ROLE` cards for each role/permission tier, and the **auth `FLOW`**
+  (sign-up, sign-in, session, password reset). Most access rules connect back here.
+- Routes/screens → `PAGE` cards. Reusable UI building blocks → `COMPONENT` cards.
+- The handful of journeys that define the product (onboarding, checkout, "create X")
+  → `FLOW` cards, each linking the `PAGE`s, `API`s, and `DATATYPE`s it touches.
+
+## Step 4 — Follow the edges
+
+- Third-party services and APIs you call → `EXTERNAL`.
+- Scheduled or background work → `JOB`. Domain events / webhooks / queue messages →
+  `EVENT`. Connect producers and consumers.
+
+## Step 5 — Zoom in (micro)
+
+Now, and only now, descend — and only into areas that are central, complex, or risky:
+
+- Hydrate before you edit: `get_card` / `traverse` with `connected: "full"` so you see a
+  card with all its neighbors at once.
+- Add the granular cards, the detailed `FLOW`s, the `STATE` machines, and the focused
+  `DIAGRAM`s for that neighborhood. Keep mermaid node IDs = handles.
+- Resist detailing quiet, stable areas to the same depth. Detail is a cost; spend it where
+  it changes a reader's understanding.
+
+## Step 6 — Interrogate (ask the user)
+
+Ask targeted questions where the code is silent or ambiguous — never what you can read:
+
+- **Intent**: why does this exist; what problem does it solve?
+- **Priority & roadmap**: what's actively built vs. aspirational vs. deprecated?
+- **Hidden rules**: business constraints, invariants, "never do X" rules not encoded in code.
+- **Boundaries**: what's in scope for this plan, what's intentionally left out?
+
+Fold the answers into card bodies and `PLAN-PROJECT` conventions. Prefer a few sharp
+questions over a long interview; batch them.
+
+## Step 7 — Find gaps in the plan
+
+This is where you earn your keep. Step back from the individual cards and judge the plan
+as an architecture for a *real, well-built* product. The user is relying on you to surface
+**blind spots** — what they haven't considered, forgot, or don't know to ask about. Read
+the plan the way a seasoned engineer reviews a design doc: assume something important is
+missing, and go find it. This matters more than any single card you write.
+
+**First, a quick hygiene sweep** (mechanical, cheap, not the point): `check_integrity` for
+orphans, `list_cards connected:false` for islands, lint for dangling `[[links]]`/refs (W004)
+and unresolved structured refs (E005), plus code with no card and `built` cards with no
+code. Fix or note these and move on — they're table stakes.
+
+**Then the real review.** Run these lenses across each area *and* the whole — but calibrate
+to the project's stage and scope; a weekend prototype and a production system have very
+different bars, so treat the list as a menu to *spot* what's missing, then raise only what
+genuinely matters here:
+
+- **Unhappy paths** — the plan almost always models the success case. Where are the errors,
+  empty states, validation failures, timeouts, retries, conflicts, partial failures, and
+  idempotency? Every `FLOW` needs its failure branches; every `STATE` its dead-ends.
+- **Lifecycle completeness** — for each entity, not just create/read but edit, archive,
+  delete, restore — and the irreversible/money cases (refund, cancel, revoke, expire).
+- **Auth & access** — is there a `ROLE`/permission answer for *every* `API` and `PAGE`?
+  Who must NOT be able to do each thing? Tenant/data isolation?
+- **Cross-cutting concerns plans routinely forget** — security (authz on every endpoint,
+  input validation, secrets handling), privacy/PII and data retention/deletion, audit
+  logging, observability (logs, metrics, alerts), rate limiting and abuse, pagination and
+  filtering on every list, caching, migrations, backups/disaster recovery, notifications
+  and email, i18n/accessibility, a testing strategy, admin/moderation tooling,
+  onboarding/empty states, and billing edge cases wherever money is involved.
+- **Scale & performance** — N+1s, hot paths, unbounded lists, synchronous work that should
+  be a `JOB`, `EVENT`s with no consumer, `EXTERNAL`s with no failure handling.
+- **End-to-end coherence** — can a user actually *complete* each journey with the cards as
+  drawn? Do the flows connect, or are there islands and dead ends?
+- **Rebuildability** — the master test: could someone rebuild this area from its cards and
+  connections alone? Whatever they'd have to guess or reverse-engineer is the gap.
+- **Domain blind spots** — bring knowledge of the product's domain: what do well-built apps
+  of this kind reliably have that this plan doesn't?
+
+For each likely gap, decide: an obvious omission → propose a `planned` card; a genuine
+judgment call → ask the user, don't silently assume. The job is to turn unknown-unknowns
+into decisions the user has actually made.
+
+## Step 8 — Recommend, tastefully
+
+Propose; don't impose. After a pass, give the user a short, prioritized list, and separate
+the two kinds of finding:
+
+- **"You likely forgot this"** — high-confidence omissions a production app needs.
+- **"Consider whether you need this"** — judgment calls that depend on scope and intent.
+
+Keep it to the few highest-value items, each with a one-line *why* and the card(s) it
+implies. Capture confirmed gaps as `status: planned` cards — visible as intent, honest
+about not existing yet. Suggest structural cleanups (split an overloaded card, add a
+missing `STATE`, connect two islands) but leave the call to the user. Taste means proposing
+the smallest set of changes that most improves the plan — not the most cards.
+
+## Status & sync discipline
+
+- `planned → building → built → verified`. Mark `built` when code exists; promote to
+  `verified` only after you've checked the card against the actual implementation.
+- When reverse-engineering shipped code, default new cards to `built`, then verify in a
+  second pass — don't claim `verified` you haven't earned.
+- After reconciling the plan with code, commit the plan, then `set_sync_point` to mark the
+  reconciliation. Change history is git (`diff_plan`, `plan_log`) — never stamp dirty
+  flags, changelogs, or timestamps into cards.
+- The opposite direction — bringing **code** up to a changed **plan** ("sync the plan to
+  the code") — is its own loop, documented in *Syncing the plan to code* in `SKILL.md`:
+  `diff_plan` → `traverse` the blast radius → update code → verify → `set_sync_point`. For a
+  large diff, orchestrate it (a sub-agent per non-overlapping area — split on file boundaries
+  so no two agents edit the same file, and give each card to exactly one agent so concurrent
+  `update_card`s can't clobber each other) and always verify the agents' work yourself before
+  setting the marker.
+- Building something new also goes **plan-first**: don't edit code first — read the affected
+  neighborhood, express the desired end state as cards (new work as `planned`) with their
+  connections wired, get sign-off on the plan diff, then run that same code-up-to-plan loop and
+  reconcile (`check_integrity` for orphans, status bumps, `set_sync_point`). In plan mode, where
+  writes are blocked, read the plan heavily to model the project fast and present the card edits
+  you'll make. Full steps in *Changing code: plan-first* in `SKILL.md`.

package/skill/types/plan.md

@@ -12,6 +12,25 @@ Keep it **short**. Three rules:
 | Field | Type | Notes |
 |---|---|---|
 | `scope` | string | area for scoped plans, e.g. `frontend`; omit for `plan.md` |
+| `connected_repos` | list | sibling repos this project coordinates with (on `PLAN-PROJECT` only) — see below |
+
+## Connected repos (multi-repo)
+
+When one change spans several sibling repos, declare them on `PLAN-PROJECT` so an agent can
+reach each one with the MCP `repo:` selector. These are **repo-level links, not card
+connections** — cards never reference another repo's cards, and each plan still lints alone.
+Each entry has a lowercase `name` (the `repo:` selector value), a `path` relative to this
+repo's root, and a one-line `description`. Paths are local topology — never lint-checked.
+
+```yaml
+connected_repos:
+  - name: pyramid-server
+    path: ../pyramid-server
+    description: Back-end API for Pyramid, written in Go.
+```
+
+Manage these with `add_connected_repo` / `list_connected_repos` / `remove_connected_repo`
+(MCP) or `constellation repos` (CLI), not by hand-editing unless you prefer to.
 
 Example — `constellation/plan.md`:
 

package/viewer/dist/assets/{arc-Kj6pF3JI.js → arc-CMMRgIq9.js}

@@ -1 +1 @@
-import{n as e,t}from"./path-BWPyau1x.js";import{a as n,c as r,d as i,f as a,i as o,l as s,m as c,n as l,o as u,p as d,r as f,u as p}from"./dist-CFOOgrqc.js";function m(e){return e.innerRadius}function h(e){return e.outerRadius}function g(e){return e.startAngle}function _(e){return e.endAngle}function v(e){return e&&e.padAngle}function y(e,t,n,r,i,a,o,s){var c=n-e,l=r-t,u=o-i,d=s-a,f=d*c-u*l;if(!(f*f<1e-12))return f=(u*(t-a)-d*(e-i))/f,[e+f*c,t+f*l]}function b(e,t,n,r,i,a,o){var c=e-n,l=t-r,u=(o?a:-a)/d(c*c+l*l),f=u*l,p=-u*c,m=e+f,h=t+p,g=n+f,_=r+p,v=(m+g)/2,y=(h+_)/2,b=g-m,x=_-h,S=b*b+x*x,C=i-a,w=m*_-g*h,T=(x<0?-1:1)*d(s(0,C*C*S-w*w)),E=(w*x-b*T)/S,D=(-w*b-x*T)/S,O=(w*x+b*T)/S,k=(-w*b+x*T)/S,A=E-v,j=D-y,M=O-v,N=k-y;return A*A+j*j>M*M+N*N&&(E=O,D=k),{cx:E,cy:D,x01:-f,y01:-p,x11:E*(i/C-1),y11:D*(i/C-1)}}function x(){var s=m,x=h,S=e(0),C=null,w=g,T=_,E=v,D=null,O=t(k);function k(){var e,t,m=+s.apply(this,arguments),h=+x.apply(this,arguments),g=w.apply(this,arguments)-r,_=T.apply(this,arguments)-r,v=l(_-g),k=_>g;if(D||=e=O(),h<m&&(t=h,h=m,m=t),!(h>1e-12))D.moveTo(0,0);else if(v>c-1e-12)D.moveTo(h*u(g),h*a(g)),D.arc(0,0,h,g,_,!k),m>1e-12&&(D.moveTo(m*u(_),m*a(_)),D.arc(0,0,m,_,g,k));else{var A=g,j=_,M=g,N=_,P=v,F=v,I=E.apply(this,arguments)/2,L=I>1e-12&&(C?+C.apply(this,arguments):d(m*m+h*h)),R=p(l(h-m)/2,+S.apply(this,arguments)),z=R,B=R,V,H;if(L>1e-12){var U=o(L/m*a(I)),W=o(L/h*a(I));(P-=U*2)>1e-12?(U*=k?1:-1,M+=U,N-=U):(P=0,M=N=(g+_)/2),(F-=W*2)>1e-12?(W*=k?1:-1,A+=W,j-=W):(F=0,A=j=(g+_)/2)}var G=h*u(A),K=h*a(A),q=m*u(N),J=m*a(N);if(R>1e-12){var Y=h*u(j),X=h*a(j),Z=m*u(M),Q=m*a(M),$;if(v<i)if($=y(G,K,Z,Q,Y,X,q,J)){var ee=G-$[0],te=K-$[1],ne=Y-$[0],re=X-$[1],ie=1/a(f((ee*ne+te*re)/(d(ee*ee+te*te)*d(ne*ne+re*re)))/2),ae=d($[0]*$[0]+$[1]*$[1]);z=p(R,(m-ae)/(ie-1)),B=p(R,(h-ae)/(ie+1))}else z=B=0}F>1e-12?B>1e-12?(V=b(Z,Q,G,K,h,B,k),H=b(Y,X,q,J,h,B,k),D.moveTo(V.cx+V.x01,V.cy+V.y01),B<R?D.arc(V.cx,V.cy,B,n(V.y01,V.x01),n(H.y01,H.x01),!k):(D.arc(V.cx,V.cy,B,n(V.y01,V.x01),n(V.y11,V.x11),!k),D.arc(0,0,h,n(V.cy+V.y11,V.cx+V.x11),n(H.cy+H.y11,H.cx+H.x11),!k),D.arc(H.cx,H.cy,B,n(H.y11,H.x11),n(H.y01,H.x01),!k))):(D.moveTo(G,K),D.arc(0,0,h,A,j,!k)):D.moveTo(G,K),!(m>1e-12)||!(P>1e-12)?D.lineTo(q,J):z>1e-12?(V=b(q,J,Y,X,m,-z,k),H=b(G,K,Z,Q,m,-z,k),D.lineTo(V.cx+V.x01,V.cy+V.y01),z<R?D.arc(V.cx,V.cy,z,n(V.y01,V.x01),n(H.y01,H.x01),!k):(D.arc(V.cx,V.cy,z,n(V.y01,V.x01),n(V.y11,V.x11),!k),D.arc(0,0,m,n(V.cy+V.y11,V.cx+V.x11),n(H.cy+H.y11,H.cx+H.x11),k),D.arc(H.cx,H.cy,z,n(H.y11,H.x11),n(H.y01,H.x01),!k))):D.arc(0,0,m,N,M,k)}if(D.closePath(),e)return D=null,e+``||null}return k.centroid=function(){var e=(+s.apply(this,arguments)+ +x.apply(this,arguments))/2,t=(+w.apply(this,arguments)+ +T.apply(this,arguments))/2-i/2;return[u(t)*e,a(t)*e]},k.innerRadius=function(t){return arguments.length?(s=typeof t==`function`?t:e(+t),k):s},k.outerRadius=function(t){return arguments.length?(x=typeof t==`function`?t:e(+t),k):x},k.cornerRadius=function(t){return arguments.length?(S=typeof t==`function`?t:e(+t),k):S},k.padRadius=function(t){return arguments.length?(C=t==null?null:typeof t==`function`?t:e(+t),k):C},k.startAngle=function(t){return arguments.length?(w=typeof t==`function`?t:e(+t),k):w},k.endAngle=function(t){return arguments.length?(T=typeof t==`function`?t:e(+t),k):T},k.padAngle=function(t){return arguments.length?(E=typeof t==`function`?t:e(+t),k):E},k.context=function(e){return arguments.length?(D=e??null,k):D},k}export{x as t};
+import{n as e,t}from"./path-BWPyau1x.js";import{a as n,c as r,d as i,f as a,i as o,l as s,m as c,n as l,o as u,p as d,r as f,u as p}from"./dist-DzXuQd4N.js";function m(e){return e.innerRadius}function h(e){return e.outerRadius}function g(e){return e.startAngle}function _(e){return e.endAngle}function v(e){return e&&e.padAngle}function y(e,t,n,r,i,a,o,s){var c=n-e,l=r-t,u=o-i,d=s-a,f=d*c-u*l;if(!(f*f<1e-12))return f=(u*(t-a)-d*(e-i))/f,[e+f*c,t+f*l]}function b(e,t,n,r,i,a,o){var c=e-n,l=t-r,u=(o?a:-a)/d(c*c+l*l),f=u*l,p=-u*c,m=e+f,h=t+p,g=n+f,_=r+p,v=(m+g)/2,y=(h+_)/2,b=g-m,x=_-h,S=b*b+x*x,C=i-a,w=m*_-g*h,T=(x<0?-1:1)*d(s(0,C*C*S-w*w)),E=(w*x-b*T)/S,D=(-w*b-x*T)/S,O=(w*x+b*T)/S,k=(-w*b+x*T)/S,A=E-v,j=D-y,M=O-v,N=k-y;return A*A+j*j>M*M+N*N&&(E=O,D=k),{cx:E,cy:D,x01:-f,y01:-p,x11:E*(i/C-1),y11:D*(i/C-1)}}function x(){var s=m,x=h,S=e(0),C=null,w=g,T=_,E=v,D=null,O=t(k);function k(){var e,t,m=+s.apply(this,arguments),h=+x.apply(this,arguments),g=w.apply(this,arguments)-r,_=T.apply(this,arguments)-r,v=l(_-g),k=_>g;if(D||=e=O(),h<m&&(t=h,h=m,m=t),!(h>1e-12))D.moveTo(0,0);else if(v>c-1e-12)D.moveTo(h*u(g),h*a(g)),D.arc(0,0,h,g,_,!k),m>1e-12&&(D.moveTo(m*u(_),m*a(_)),D.arc(0,0,m,_,g,k));else{var A=g,j=_,M=g,N=_,P=v,F=v,I=E.apply(this,arguments)/2,L=I>1e-12&&(C?+C.apply(this,arguments):d(m*m+h*h)),R=p(l(h-m)/2,+S.apply(this,arguments)),z=R,B=R,V,H;if(L>1e-12){var U=o(L/m*a(I)),W=o(L/h*a(I));(P-=U*2)>1e-12?(U*=k?1:-1,M+=U,N-=U):(P=0,M=N=(g+_)/2),(F-=W*2)>1e-12?(W*=k?1:-1,A+=W,j-=W):(F=0,A=j=(g+_)/2)}var G=h*u(A),K=h*a(A),q=m*u(N),J=m*a(N);if(R>1e-12){var Y=h*u(j),X=h*a(j),Z=m*u(M),Q=m*a(M),$;if(v<i)if($=y(G,K,Z,Q,Y,X,q,J)){var ee=G-$[0],te=K-$[1],ne=Y-$[0],re=X-$[1],ie=1/a(f((ee*ne+te*re)/(d(ee*ee+te*te)*d(ne*ne+re*re)))/2),ae=d($[0]*$[0]+$[1]*$[1]);z=p(R,(m-ae)/(ie-1)),B=p(R,(h-ae)/(ie+1))}else z=B=0}F>1e-12?B>1e-12?(V=b(Z,Q,G,K,h,B,k),H=b(Y,X,q,J,h,B,k),D.moveTo(V.cx+V.x01,V.cy+V.y01),B<R?D.arc(V.cx,V.cy,B,n(V.y01,V.x01),n(H.y01,H.x01),!k):(D.arc(V.cx,V.cy,B,n(V.y01,V.x01),n(V.y11,V.x11),!k),D.arc(0,0,h,n(V.cy+V.y11,V.cx+V.x11),n(H.cy+H.y11,H.cx+H.x11),!k),D.arc(H.cx,H.cy,B,n(H.y11,H.x11),n(H.y01,H.x01),!k))):(D.moveTo(G,K),D.arc(0,0,h,A,j,!k)):D.moveTo(G,K),!(m>1e-12)||!(P>1e-12)?D.lineTo(q,J):z>1e-12?(V=b(q,J,Y,X,m,-z,k),H=b(G,K,Z,Q,m,-z,k),D.lineTo(V.cx+V.x01,V.cy+V.y01),z<R?D.arc(V.cx,V.cy,z,n(V.y01,V.x01),n(H.y01,H.x01),!k):(D.arc(V.cx,V.cy,z,n(V.y01,V.x01),n(V.y11,V.x11),!k),D.arc(0,0,m,n(V.cy+V.y11,V.cx+V.x11),n(H.cy+H.y11,H.cx+H.x11),k),D.arc(H.cx,H.cy,z,n(H.y11,H.x11),n(H.y01,H.x01),!k))):D.arc(0,0,m,N,M,k)}if(D.closePath(),e)return D=null,e+``||null}return k.centroid=function(){var e=(+s.apply(this,arguments)+ +x.apply(this,arguments))/2,t=(+w.apply(this,arguments)+ +T.apply(this,arguments))/2-i/2;return[u(t)*e,a(t)*e]},k.innerRadius=function(t){return arguments.length?(s=typeof t==`function`?t:e(+t),k):s},k.outerRadius=function(t){return arguments.length?(x=typeof t==`function`?t:e(+t),k):x},k.cornerRadius=function(t){return arguments.length?(S=typeof t==`function`?t:e(+t),k):S},k.padRadius=function(t){return arguments.length?(C=t==null?null:typeof t==`function`?t:e(+t),k):C},k.startAngle=function(t){return arguments.length?(w=typeof t==`function`?t:e(+t),k):w},k.endAngle=function(t){return arguments.length?(T=typeof t==`function`?t:e(+t),k):T},k.padAngle=function(t){return arguments.length?(E=typeof t==`function`?t:e(+t),k):E},k.context=function(e){return arguments.length?(D=e??null,k):D},k}export{x as t};

package/viewer/dist/assets/architecture-7EHR7CIX-Cbb-syEI.js

@@ -0,0 +1 @@
+import"./chunk-NNHCCRGN-DlpIbxXb.js";import{x as e}from"./mermaid-parser.core-xhSeYiZo.js";export{e as createArchitectureServices};