otacon 0.1.2 → 0.1.4

package/dist/skills/otacon/SKILL.md

@@ -0,0 +1,250 @@
+---
+name: otacon
+description: Plan a feature through an otacon review session: grill interview, schema'd plan, phone review with anchored comments, approved plan saved to a home archive (and your project on Save). Use when the user asks to plan something with otacon, types /otacon, or wants a reviewed implementation plan before coding. Replaces native plan mode. Also resumes and amends an implemented plan when run from inside its build worktree.
+---
+
+<!-- managed by `otacon install` — reinstall overwrites this file. -->
+
+# Otacon plan session protocol
+
+Run plan reviews through the otacon CLI instead of your native plan mode. The
+user reviews in a browser. Every `otacon`
+command prints exactly one JSON line on stdout. Exit 0 = proceed; exit 1 = a
+machine-readable error you can fix (read the JSON); exit 2 = you invoked it wrong.
+
+## Hard implementation gate
+
+When this skill is triggered, you MUST NOT create, edit, delete, or format project
+files, run code-modifying commands, or implement the requested change until a
+`otacon wait` event returns `{"event":"approved",...,"implement":true}`.
+
+Before that event, allowed actions are only:
+- `otacon start` / `otacon status` / `otacon open` / `otacon progress` /
+  `otacon ask` / `otacon wait` / `otacon submit` / `otacon answer`.
+- Read-only research commands.
+- Writing the plan and resolutions files under the session's home dir (`~/.otacon/sessions/<id>/`, the `plan` path `start` prints).
+
+A user request phrased as "can you make/fix/implement..." is still a plan-review
+request when this skill is active. Approval is not implied by the original request.
+
+## Starting: resume an amendment, or plan fresh
+
+Before `otacon start`, check where you are: run `otacon status`. If its output
+carries a `resumeCandidate`, you are standing inside a build worktree otacon
+created for a finished plan: a chance to AMEND that plan in place instead of
+spawning a second worktree.
+
+- Read the candidate plan at `resumeCandidate.plan` and judge whether the user's
+  request is about THAT feature.
+  - **Clearly unrelated** (a different feature) → just `otacon start` a fresh
+    session and ignore the candidate.
+  - **Related, or you are unsure** → ask the user, here in the terminal, whether to
+    resume and amend the existing plan or start new. This is the ONE question that
+    does not go through `otacon ask` (no session is open yet); wait for the answer
+    before acting.
+- On **resume**: `otacon resume` (it auto-detects the session from this worktree,
+  reopens it to `revising`, and prints the `plan` path). SKIP research and grill,
+  since the plan exists. Edit that `plan` file into revision N+1 directly from the user's
+  request (grill only if it is genuinely ambiguous), `otacon submit`, then go to
+  the **Review loop** (step 5). The review diffs against the approved revision.
+- No `resumeCandidate` → the normal flow below.
+
+## The loop
+
+1. `otacon start --title <kebab-title>` **first, before you research** — it mints
+   the session and prints the review URL plus the `plan` draft path (under
+   `~/.otacon/sessions/<id>/`). Tell the user to open the URL (`otacon open`
+   launches it in their browser) so they can watch the whole thing from the first second.
+   `--quick` skips the interview — only when the user explicitly asks.
+2. **Research the codebase.** On supported agents the daemon now auto-streams your
+   tool calls, text, and thinking to the reviewer's now-playing console, so it
+   already sees the routine work. Use `otacon progress "<what you're doing>"` for
+   OCCASIONAL highlights and chapter markers (a milestone, a phase boundary, "what
+   I'm about to do next"), not per-step narration. It is the universal floor: on an
+   agent with no auto-capture those notes are the ONLY thing keeping the now-playing
+   bar alive, so still drop one whenever you start a chunk of work the user can't
+   otherwise see. It is a non-blocking one-liner that feeds the live stream and the
+   draft chip; no answer comes back, so never park on it. Read enough to propose
+   answers, not collect questions.
+3. **Grill** (mandatory unless --quick): Interview me relentlessly about every
+   aspect of this plan until we reach a shared understanding. Walk down each branch
+   of the design tree, resolving dependencies between decisions one-by-one. For
+   each question, provide your recommended answer. Explore the code before asking.
+   Never ask what the code can answer.
+   - `otacon ask --question "..." --options "A|B|C" --recommend A` — always lead
+     with your recommended answer. `--multi` for multi-select; omit `--options`
+     for free text. The user can always answer with free-form custom text instead
+     of (or alongside) the chips, so frame options as a starting point, not a cage.
+   - Independent questions whose answers don't shape each other? Post them in one
+     call: `otacon ask --batch questions.json` (or `--batch -` for stdin) — a JSON
+     array of the same specs (`{question, options?, recommend?, multi?}`). They land
+     as ordinary cards; loop `wait` to collect each answer. Dependent questions
+     still go one at a time.
+   - Park for the answer: `otacon wait --timeout 540` (set the Bash tool timeout
+     to 600000 ms). The answer arrives as `{"event":"answer","question":"q<n>",...}`.
+4. **Draft** the plan at the `plan` path `start` printed (`~/.otacon/sessions/<id>/plan.md`) in the schema below, then
+   `otacon submit`. On exit 1, fix every reported lint issue and resubmit until
+   accepted. After a clean submit, stop all implementation work and park in
+   `otacon wait`; only an `approved` event with `implement:true` enters the
+   Implement loop.
+5. **Review loop** — park in `otacon wait --timeout 540` (Bash timeout 600000 ms)
+   and handle the one event it prints:
+   - `comments` → revise plan.md; write `resolutions.json` as
+     `{"changelog":"what changed","threads":{"t1":"how you resolved it"}}` with
+     one reply per comment thread; `otacon submit --resolutions resolutions.json`
+     (loop on lint errors); park again. A `comments` batch with `"final":true` is
+     the reviewer's **comment & approve**: resolve every thread the usual way, but
+     your next clean submit **finalizes** — you'll get `approved` (which may carry
+     `implement:true`), not another review round. So fold them all in, submit, then
+     park and handle the `approved` that follows (do NOT expect more comments).
+   - `question` → `otacon answer <q-id> --body "..."` (or `--file`); park again. A
+     `question` may carry `replyTo` (a follow-up on an earlier question) — skim that
+     thread's prior turns for context, but still answer the new `q<n>`.
+   - `answer` → use it and continue; park again whenever you are waiting.
+   - `timeout` → park again immediately. A timeout is NEVER completion.
+   - `approved` → the plan is saved at `path`. Plain `approved` (Save, no
+     `implement`) → print a one-line summary naming where it was saved (`path`),
+     then STOP. `approved` **with `implement:true`** → read the plan at `path` to
+     guide the build and enter the **Implement loop** (below) — do NOT stop; the
+     session is now `implementing`.
+   - `deleted` → the user deleted this session in the review UI. It is over:
+     STOP. There is no approved plan.
+6. **Never end your turn while the session is open.** Nothing to do = park in
+   `otacon wait` again. Confused, crashed, or compacted? `otacon status` returns
+   the open session, revision, and pending events — resume the loop from it.
+
+## CLI quick reference
+
+- `otacon start --title <t> [--quick]` · `otacon resume [--session <id>]` ·
+  `otacon progress "<note>"` (occasional highlights / chapter markers; the activity
+  floor on agents without auto-capture) ·
+  `otacon ask ...` · `otacon wait --timeout 540` · `otacon submit [--resolutions f]` ·
+  `otacon answer <q> --body "..."` · `otacon implement-done [--pr <url>] [--failed]` ·
+  `otacon status` · `otacon open` · `otacon config [get <key>]`
+
+## Implement loop (on `approved` with `implement:true`)
+
+You are the **orchestrator**: you only coordinate and mark progress
+(`otacon progress` at phase boundaries, an occasional chapter marker rather than
+every action; on supported agents the now-playing console already streams the work).
+Every phase's real work runs in a fresh native subagent (Task tool) so your own
+context stays lean.
+
+1. **Setup.** Read the plan from the home archive at the event `path`.
+   - **Amending** (you resumed this session, so its build worktree already exists
+     and you are standing in it): do NOT create a worktree. `cd` into
+     `<worktree.dir>/<slug>`, make sure you are on `otacon/impl-<slug>`, and build
+     on top of the existing commits. Pushing later updates the SAME PR.
+   - **Fresh** (no existing worktree): branch off the repo's default-branch HEAD and
+     create the worktree under `worktree.dir` (`otacon config get worktree.dir`,
+     default `~/.otacon/worktrees`, outside the repo):
+     `git worktree add <worktree.dir>/<slug> -b otacon/impl-<slug>` (off the default
+     branch).
+   Drop a `otacon progress` highlight at each phase boundary throughout, not at
+   every step.
+2. **Per phase, in order** (read the phases from the home plan at the event `path`;
+   on an amendment, implement only the phases this revision changed, using the
+   changelog and the diff to scope):
+   - `otacon progress "phase N — implementing"` (one marker per phase); spawn an
+     **implement+test**
+     subagent (Task tool) scoped to that phase's Goal/Files/Verification — it
+     implements and runs the phase Verification plus the repo gates.
+   - spawn a **separate** `/code-review --fix` subagent on the phase's working
+     diff; it applies findings; re-review. (`/code-review` effort is config — start
+     moderate so false positives don't become needless pauses.)
+   - **clean + green** → commit the phase and continue. **Blocked** (tests stay red,
+     review still flags, or a subagent is stuck) → on the FIRST blocker,
+     `otacon ask` with options `retry|skip|abort|guidance`, park in `otacon wait`,
+     and act on the answer. No auto-retry.
+3. **Finish.** On a **fresh** build, open a PR against the default branch with
+   `gh pr create` (PR body = the plan summary + the per-phase log; fall back to the
+   local branch + path when there is no remote). On an **amendment**, the PR already
+   exists: push the branch and it updates, so reuse its URL (it is on the session;
+   `otacon status` reports `prUrl`). Either way finish with
+   `otacon implement-done --pr <url>`. On abort, run `otacon implement-done --failed`.
+
+While `implementing` the Stop hook still keeps you on the line — never end the turn
+until `implement-done`.
+
+## Plan schema (linted on submit)
+
+Frontmatter (`title`, `session`, `revision`, `status`, `created`), then these
+H2 sections in order — the five required ones plus optional review-altitude
+sections slotted in place (include them when the change warrants; skip them on
+trivial plans): `## Summary` (≤5 lines, lead with a diagram — see below) ·
+*(optional)* `## Contract` (≤12 lines —
+the interface surface the reviewer signs off instead of reading code: inputs,
+outputs, types, errors; one signature fence is fine under the 1-fence rule) ·
+`## Decisions` (entries ≤3 lines, `- D<n>: ... ← q<n>` citing the grill answer
+that produced it, or `[assumed]`) · *(optional)* `## Impact` (≤10 lines — blast
+radius: the upstream modules this plan leans on and the downstream modules it can
+break; a dependency mermaid is fine under the 1-fence rule) · `## Phases`
+(`### Phase <n> — <name>`, each with `Goal:` ≤3 lines, `Files:` list,
+`Verification:` ≤3 lines plus an optional ```gwt scenario block — see below,
+optional collapsible `#### Details` block) ·
+`## Risks` (≤5 items, ≤2 lines each) ·
+`## Open Questions`. Mermaid / code / `before`+`after` fences are budget-exempt,
+max one per read-path section; the markdown-native review visuals below share a
+separate per-section cap. Details may elaborate on the read path, never
+introduce new scope.
+
+**Lead with a diagram.** Put a ```mermaid state / sequence / flow diagram right
+under the `## Summary` headline — strongly recommended on ~90% of plans, so the
+reviewer grasps the change's shape before reading prose. Keep the headline as the ≤5-line
+Summary.
+
+## Visuals — prefer them over prose where they carry the information
+
+Four markdown-native primitives the review UI styles. They degrade to readable
+markdown if rendering fails, and a comment can anchor to one specific risk, row,
+or callout.
+
+- **Callouts** — a blockquote whose first line is a type marker
+  (`[!risk]`, `[!note]`, `[!decision]`, `[!assumption]`). Risks and
+  assumptions SHOULD be callouts, not bullets buried in prose:
+  > [!risk]
+  > The JWT cutover locks out sessions issued before it.
+- **Decision matrix** — a GFM table comparing options, the chosen row led by a
+  `✓`. A Decisions section weighing 2+ options SHOULD use a matrix:
+  | Pick | Option | Tradeoff                        |
+  | ---- | ------ | ------------------------------- |
+  | ✓    | RS256  | rotate keys without redeploy    |
+  |      | HS256  | shared secret on every verifier |
+- **Scope pills** — inline tags `[new]` `[breaking]` `[risky]` `[deletes]`
+  for flagging scope mid-sentence ("adds a [new] issuer; [breaking] cookie removal").
+- **Behavioral assertions** — a ```gwt fence inside a phase's `Verification`
+  holding one or more Given/When/Then scenarios (blank line between scenarios;
+  `And`/`But` continue a clause). They render as scenario cards that double as
+  the human's approve checklist (Test-Driven Review), so write the observable
+  behavior the reviewer signs off, not the test code:
+  ```gwt
+  Given a plan with no Contract section
+  When the agent submits it
+  Then the lint passes and review opens
+  ```
+  Capped at 6 scenarios per block; must sit under `Verification`.
+
+When plan content is shaped as a hierarchy or tree (a taxonomy, a doc or file
+structure, a nested option space, a state hierarchy, a decision tree), draw it as a
+```mermaid diagram, not as a monospace nested outline in a ```text fence: an outline
+forces the reviewer to reconstruct the shape line by line, while a diagram shows it at a
+glance. `graph TD` (a top-down flowchart) is the natural default; pick whatever shape
+reads best (a mindmap, a state diagram, etc. when they fit). Put the tree diagram in the
+section that owns that structure (Contract, Impact, or a phase's Details); `mermaid`
+diagrams no longer count toward the per-section fence cap, so a lead diagram and a
+structural one can coexist.
+
+Callouts and matrices are budget-exempt but capped (default 2 per read-path
+section); pills are free. Reach for a visual when it carries the point better
+than a sentence — never as decoration.
+
+## Rules
+
+- Never use native plan mode, AskUserQuestion, or any built-in question UI while
+  the session is open: every question goes through `otacon ask`. The sole exception
+  is the resume-vs-new question at the very start, before any session exists.
+- If you notice you edited project files before `approved implement:true`, stop
+  immediately, disclose the mistake, and ask whether to revert or keep the
+  uncommitted changes.
+- Long review or build ahead? Remind the user to keep the Mac awake: `caffeinate -i`
+  while the session runs.

package/dist/ui/assets/{arc-KT3ZnaMp.js → arc-BUR2DxNA.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-BcowSnUl.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-ZqsueX9_.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/dist/ui/assets/architecture-7EHR7CIX-TTokq2IO.js

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