chamba 0.0.1 → 0.2.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +66 -1
- package/dist/cli.js +1691 -0
- package/dist/server.js +1919 -0
- package/inject/annotate.js +49 -0
- package/package.json +24 -3
- package/skill/README.md +12 -0
- package/skill/SKILL.md +285 -0
- package/web/assets/abnfDiagram-VRR7QNED-C5V2hrtE.js +1 -0
- package/web/assets/arc-d7OTmxZy.js +1 -0
- package/web/assets/architectureDiagram-ZJ3FMSHR--CztaeAS.js +36 -0
- package/web/assets/blockDiagram-677ZJIJ3-DkA5Z_uK.js +132 -0
- package/web/assets/c4Diagram-LMCZKHZV-C78dI0l-.js +10 -0
- package/web/assets/channel-D9AxU8kk.js +1 -0
- package/web/assets/chunk-2Q5K7J3B-LBNP12XV.js +1 -0
- package/web/assets/chunk-32BRIVSS-DZoXrhCs.js +1 -0
- package/web/assets/chunk-5VM5RSS4-CPjoRxF_.js +15 -0
- package/web/assets/chunk-EX3LRPZG-DSlL8FE9.js +231 -0
- package/web/assets/chunk-JWPE2WC7-BjbBLYge.js +1 -0
- package/web/assets/chunk-MOJQB5TN-DCKqdaDr.js +88 -0
- package/web/assets/chunk-RYQCIY6F-D5yAURhE.js +1 -0
- package/web/assets/chunk-V7JOEXUC-DKY2sn06.js +206 -0
- package/web/assets/chunk-VR4S4FIN-DGiVMHh6.js +1 -0
- package/web/assets/chunk-XXDRQBXY-CUI1Tkrr.js +1 -0
- package/web/assets/classDiagram-OUVF2IWQ-D7gWuzIF.js +1 -0
- package/web/assets/classDiagram-v2-EOCWNBFH-D7gWuzIF.js +1 -0
- package/web/assets/cose-bilkent-JH36ORCC-Ao3LzalV.js +1 -0
- package/web/assets/cynefin-VYW2F7L2-7JQwpRwH.js +178 -0
- package/web/assets/cynefinDiagram-TSTJHNR4-BfuANy_V.js +62 -0
- package/web/assets/cytoscape.esm-DTSO7Bv0.js +331 -0
- package/web/assets/dagre-VKFMJZFB-DHVnVJCL.js +4 -0
- package/web/assets/defaultLocale-DX6XiGOO.js +1 -0
- package/web/assets/diagram-FQU43EPY-OYrtwA2f.js +3 -0
- package/web/assets/diagram-G47NLZAW-CbkLZxYp.js +24 -0
- package/web/assets/diagram-NH7WQ7WH-B0z_jTdi.js +24 -0
- package/web/assets/diagram-OA4YK3LP-BRu_2nwx.js +30 -0
- package/web/assets/diagram-WEI45ONY-B9cpw86D.js +41 -0
- package/web/assets/ebnfDiagram-CCIWWBDH-DaBQ7T4R.js +1 -0
- package/web/assets/erDiagram-Q63AITRT-D6PQiFj3.js +85 -0
- package/web/assets/flowDiagram-23GEKE2U-p_8Wj7It.js +156 -0
- package/web/assets/ganttDiagram-NO4QXBWP-BZBwuqu3.js +292 -0
- package/web/assets/gitGraphDiagram-IHSO6WYX-DyPcQ-91.js +106 -0
- package/web/assets/graph-C9eacEi8.js +1 -0
- package/web/assets/highlighted-body-OFNGDK62-Cq7RJZcn.js +1 -0
- package/web/assets/index-BN-QUr5b.js +350 -0
- package/web/assets/index-D6-LVQ5m.css +1 -0
- package/web/assets/infoDiagram-FWYZ7A6U-sAgBAeWC.js +2 -0
- package/web/assets/init-Gi6I4Gst.js +1 -0
- package/web/assets/ishikawaDiagram-FXEZZL3T-COEn9wCs.js +70 -0
- package/web/assets/journeyDiagram-5HDEW3XC-BPddPRXW.js +139 -0
- package/web/assets/kanban-definition-HUTT4EX6-B8TW97Oy.js +89 -0
- package/web/assets/katex-C5jXJg4s.js +257 -0
- package/web/assets/layout-DEXfKzaS.js +1 -0
- package/web/assets/linear-CnW5uQ_k.js +1 -0
- package/web/assets/map-Czzmt4hB.js +1 -0
- package/web/assets/mermaid.core-bOV5iNX_.js +314 -0
- package/web/assets/mindmap-definition-LN4V7U3C-Dtr4xW_-.js +96 -0
- package/web/assets/ordinal-Cboi1Yqb.js +1 -0
- package/web/assets/pegDiagram-2B236MQR-DqBITK5N.js +1 -0
- package/web/assets/pieDiagram-ENE6RG2P-DXjxZgy3.js +39 -0
- package/web/assets/quadrantDiagram-ABIIQ3AL-D4MXx3U7.js +7 -0
- package/web/assets/railroadDiagram-RFXS5EU6-LPfpHg4_.js +1 -0
- package/web/assets/requirementDiagram-TGXJPOKE-CiDswbjt.js +84 -0
- package/web/assets/sankeyDiagram-HTMAVEWB-VfN_qTEI.js +40 -0
- package/web/assets/sequenceDiagram-DBY2YBRQ-kJRIx4zm.js +162 -0
- package/web/assets/sizeCapture-X5ZJPWSS-D8vJbAt-.js +1 -0
- package/web/assets/stateDiagram-2N3HPSRC-9qku-qAj.js +1 -0
- package/web/assets/stateDiagram-v2-6OUMAXLB-DbOQICyv.js +1 -0
- package/web/assets/swimlanes-5IMT3BWC-Cdb5FDUM.js +2 -0
- package/web/assets/swimlanesDiagram-G3AALYLV-EDpLmqQv.js +8 -0
- package/web/assets/timeline-definition-FHXFAJF6-D0hyJCMm.js +120 -0
- package/web/assets/vennDiagram-L72KCM5P-KsCkGMtr.js +34 -0
- package/web/assets/wardleyDiagram-EHGQE667-B4jT_1ak.js +78 -0
- package/web/assets/xychartDiagram-FW5EYKEG-Bmy0rt8j.js +7 -0
- package/web/index.html +28 -0
package/skill/SKILL.md
ADDED
|
@@ -0,0 +1,285 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: chamba
|
|
3
|
+
description: Open a browser workspace paired to this terminal session so the human can see rendered markdown, paste screenshots the agent can read, and point at UI - one shared conversation between the terminal agent and the browser. Use when the user says /chamba, asks to "open chamba", wants to share or receive images, or wants a visual workspace alongside the terminal.
|
|
4
|
+
when_to_use: The user typed /chamba, asked to open the chamba workspace, wants to paste or be shown an image/screenshot, or wants a browser surface paired with this terminal session.
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# chamba
|
|
8
|
+
|
|
9
|
+
chamba pairs this terminal session with a browser workspace over one shared
|
|
10
|
+
conversation. The terminal stays home base; the browser is where the human reads
|
|
11
|
+
rendered markdown, pastes screenshots you can open, and points at UI. A pasted
|
|
12
|
+
image arrives as a real file path you can `Read`; anything you send back with a
|
|
13
|
+
file renders inline in their browser.
|
|
14
|
+
|
|
15
|
+
Every command is `npx chamba@latest <command>`. Conversation content prints on
|
|
16
|
+
stdout (what you read and act on); status and hints go to stderr, so a command's
|
|
17
|
+
stdout is just the messages. Using `@latest` resolves the newest published
|
|
18
|
+
version rather than a stale one npx may have cached.
|
|
19
|
+
|
|
20
|
+
## First run: the workspace
|
|
21
|
+
|
|
22
|
+
chamba keeps everything under a `.chamba/` directory in the project. The first
|
|
23
|
+
`open` creates it at the git repo root and says where (`created chamba workspace
|
|
24
|
+
at ...`); each project gets its own server on a port derived from that location,
|
|
25
|
+
so several projects run side by side without colliding. If the project has no
|
|
26
|
+
`.git`, `open` will not guess a location - ask the human where the workspace
|
|
27
|
+
should live and run `npx chamba@latest init <dir>` once (or `init --here` for the
|
|
28
|
+
current directory), then `open`. `npx chamba@latest` with no arguments (a bare
|
|
29
|
+
status) tells you whether a workspace exists yet.
|
|
30
|
+
|
|
31
|
+
## Opening a session
|
|
32
|
+
|
|
33
|
+
```
|
|
34
|
+
npx chamba@latest open --title "what this is about"
|
|
35
|
+
```
|
|
36
|
+
|
|
37
|
+
This prints a URL on stdout - give that URL to the human and ask them to open it.
|
|
38
|
+
The server starts automatically if it is not already running.
|
|
39
|
+
|
|
40
|
+
With no `--kind`, the session opens undecided: the browser shows the human a
|
|
41
|
+
chooser as their first interaction, and their pick sets the kind on this same
|
|
42
|
+
session. Your next `poll` reports the choice as a `· Session set to spec` or
|
|
43
|
+
`· Session set to everyday` line - drive the session accordingly from there. Pass
|
|
44
|
+
`--kind spec` (or `--kind everyday`) to decide up front and skip the chooser; spec
|
|
45
|
+
work adds the Draft/Mock/Diagram surfaces.
|
|
46
|
+
|
|
47
|
+
## The app tab: connecting annotation
|
|
48
|
+
|
|
49
|
+
The browser's "Your app" tab loads the human's running dev app in a frame so they can point at real UI and send you annotations.
|
|
50
|
+
That needs chamba's annotation client running inside their app: one `<script>` tag that loads `/inject/annotate.js` from this chamba server.
|
|
51
|
+
Until the app serves that script, the tab shows "Annotation layer not detected".
|
|
52
|
+
|
|
53
|
+
Wire it in when the human asks - the app tab has an "Ask the agent to set this up" button that sends you exactly that request, and it may also come in their own words:
|
|
54
|
+
|
|
55
|
+
- Use the exact tag the "not detected" banner shows; it already carries the right `src` (the origin the browser uses to reach chamba).
|
|
56
|
+
If you cannot see the banner, the tag is `<script src="<chamba-origin>/inject/annotate.js"></script>`, where `<chamba-origin>` is this project's chamba server URL - the same host and port as the `open` URL.
|
|
57
|
+
- Add it to the app's HTML entry or root layout, and guard it to development so it never ships to production.
|
|
58
|
+
Where that goes depends on the project, so adapt to what you find: the `<head>` of `index.html` for Vite, a dev-only `<Script>` in `app/layout.tsx` (or `pages/_document`) for Next, `public/index.html` for Create React App, or the real HTML entry of anything else.
|
|
59
|
+
- Have the human reload the app in the tab afterwards (or reload it yourself if you drive its dev server); the banner clears and the tab reads "connected" once the client is in.
|
|
60
|
+
|
|
61
|
+
This is one-time setup per app: once the tag is in, annotation works for every session.
|
|
62
|
+
|
|
63
|
+
## The loop
|
|
64
|
+
|
|
65
|
+
After opening (or `attach`), wait for the human:
|
|
66
|
+
|
|
67
|
+
```
|
|
68
|
+
npx chamba@latest poll
|
|
69
|
+
```
|
|
70
|
+
|
|
71
|
+
`poll` blocks until there is something to read, then prints it and returns. It
|
|
72
|
+
keeps waiting across quiet windows on its own, so a single `poll` is normally all
|
|
73
|
+
you run between actions - it returns the moment a batch arrives. After a few minutes
|
|
74
|
+
with nothing it prints `still listening - re-run chamba poll to keep waiting` to
|
|
75
|
+
stderr and exits 0; just run it again. Give it a generous command timeout, since one
|
|
76
|
+
call may block for minutes. It is safe to re-run - a batch re-delivers if you were
|
|
77
|
+
interrupted before acting.
|
|
78
|
+
|
|
79
|
+
Once you are attending a session, every exchange with the human goes through this
|
|
80
|
+
loop - `poll` to receive, `reply` to send - and that includes your own questions,
|
|
81
|
+
status updates, and "what should I do next?" checks. The human cannot see your
|
|
82
|
+
terminal, so anything you write there is invisible to them; never stop polling to
|
|
83
|
+
say or ask something in the terminal. `· Session ended` is the only line that ends the loop:
|
|
84
|
+
it means the human handed back (clicked "Hand back", ended the session, or told you
|
|
85
|
+
to stop, at which point you may run `end`). Nothing else is a reason to stop - not a
|
|
86
|
+
heartbeat, not a quiet stretch, not finishing the task, not having a question. When
|
|
87
|
+
in doubt, `poll` again. (`poll --once` does a single bounded check instead, for
|
|
88
|
+
scripts.) React to what each line says:
|
|
89
|
+
|
|
90
|
+
- A message from the human (`you: ...`): do the work, then answer with `reply` and
|
|
91
|
+
poll again. If you need something back first - a question, a choice, a
|
|
92
|
+
clarification - send that with `reply` too and keep polling for their answer;
|
|
93
|
+
never pause the loop to raise it in the terminal.
|
|
94
|
+
- An attachment line (` [file] name -> /abs/path`): that path is a real file on
|
|
95
|
+
disk. `Read` it (screenshots, mockups, logs) and act on what you see.
|
|
96
|
+
- An annotation batch (`you [N annotations]:`): the human pointed at elements in
|
|
97
|
+
the app tab. Each numbered item carries the comment, the `selector`, the `page`
|
|
98
|
+
and `viewport`, a `[shot]` screenshot path to `Read`, and - when the app is
|
|
99
|
+
React/Next - the `component:` name and its source `file:line`. Use the source
|
|
100
|
+
and selector to find the code, `Read` the shot to see the problem, fix each item,
|
|
101
|
+
then `reply`. (React 19 shows the component name but may omit `file:line` unless
|
|
102
|
+
the app opted into bippy's source tier; fall back to the selector then.)
|
|
103
|
+
- `· Session set to spec` / `· Session set to everyday`: the human picked the kind
|
|
104
|
+
for a session that opened undecided. From here drive it accordingly - spec means
|
|
105
|
+
the interview flow (`ask`, `decision`, `artifact`); everyday is open conversation.
|
|
106
|
+
- `· You moved to another session (<id>)`: the human switched sessions. Hand off
|
|
107
|
+
with `npx chamba@latest attach <id>`, then keep polling that one.
|
|
108
|
+
- `· The user moved away`: a hand-off with no target session. Informational only -
|
|
109
|
+
keep polling this session.
|
|
110
|
+
- `· Session ended`: the human handed back to the terminal. This is the only line
|
|
111
|
+
that ends the loop - stop polling and resume terminal work.
|
|
112
|
+
|
|
113
|
+
## Replying
|
|
114
|
+
|
|
115
|
+
```
|
|
116
|
+
npx chamba@latest reply on it - here is the diff you asked about
|
|
117
|
+
```
|
|
118
|
+
|
|
119
|
+
Send a file back (renders in their browser); text is optional alongside it:
|
|
120
|
+
|
|
121
|
+
```
|
|
122
|
+
npx chamba@latest reply here's the chart --image /abs/path/to/chart.png
|
|
123
|
+
```
|
|
124
|
+
|
|
125
|
+
Use `--file a,b` / `--image a,b` (comma-separated) for several files.
|
|
126
|
+
|
|
127
|
+
## Handing back
|
|
128
|
+
|
|
129
|
+
```
|
|
130
|
+
npx chamba@latest end
|
|
131
|
+
```
|
|
132
|
+
|
|
133
|
+
Run this only when the human explicitly asks to stop or hand back - never on your
|
|
134
|
+
own initiative to leave the loop. It ends the session from the terminal (the browser
|
|
135
|
+
goes read-only). The human can also hand back from the browser, which you will see
|
|
136
|
+
as `· Session ended` on your next poll.
|
|
137
|
+
|
|
138
|
+
## Spec sessions
|
|
139
|
+
|
|
140
|
+
A spec session is chamba's deepest use: a structured interview that produces a
|
|
141
|
+
spec package - a canonical markdown draft, mockups, diagrams, and a decision log -
|
|
142
|
+
in the same shared thread and the same annotation system.
|
|
143
|
+
Open one with `--kind spec`:
|
|
144
|
+
|
|
145
|
+
```
|
|
146
|
+
npx chamba@latest open --kind spec --title "checkout redesign spec"
|
|
147
|
+
```
|
|
148
|
+
|
|
149
|
+
This unlocks three surface tabs beside "Your app" - Draft, Mock, Diagram - each
|
|
150
|
+
annotatable exactly like the app tab.
|
|
151
|
+
You drive the session from the terminal with four commands (`ask`, `decision`,
|
|
152
|
+
`artifact`, `export`); the human answers, points, and annotates from the browser.
|
|
153
|
+
|
|
154
|
+
### Intake: infer the kind of work, then confirm it
|
|
155
|
+
|
|
156
|
+
A spec session opens with a free-form dump - text, pasted images, files.
|
|
157
|
+
Read all of it, infer which of four kinds of spec work this is, and confirm your
|
|
158
|
+
read with the human before diving in (they can override).
|
|
159
|
+
Record the confirmed kind with `decision` so it is on the log.
|
|
160
|
+
|
|
161
|
+
The four kinds are behaviorally distinct - they change what you do, not just a label:
|
|
162
|
+
|
|
163
|
+
- **co-spec** - no spec exists yet; you build one from scratch.
|
|
164
|
+
Start wide (goals, users, constraints, what success means), then converge; most
|
|
165
|
+
of the work is net-new question cards and a draft that grows from nothing.
|
|
166
|
+
- **review** - a spec or feature already exists and the human wants it pressure-tested.
|
|
167
|
+
Read it first against the codebase, then lead with the gaps, contradictions, and
|
|
168
|
+
unstated assumptions you find rather than with open-ended questions.
|
|
169
|
+
- **refine** - a draft exists and is roughly right; the work is sharpening.
|
|
170
|
+
Hunt vague terms, unclear edges, and missing error/empty/loading states,
|
|
171
|
+
then propose precise wording and confirm it.
|
|
172
|
+
- **feedback** - the human has a running thing and reactions to it.
|
|
173
|
+
Lean on the Your app tab and annotations: turn each pointed-at problem into a
|
|
174
|
+
decision and a draft revision.
|
|
175
|
+
|
|
176
|
+
### The interview doctrine
|
|
177
|
+
|
|
178
|
+
- Hunt ambiguity relentlessly; every vague term ("fast", "simple", "secure") is a
|
|
179
|
+
question waiting to be asked.
|
|
180
|
+
- Assume the highest standard: when you offer options, mark the one you would
|
|
181
|
+
choose as `recommended` and say why in its description.
|
|
182
|
+
- Give development cost low weight - prefer quality, simplicity, robustness,
|
|
183
|
+
scalability, and long-term maintainability; surface the trade-off and let the
|
|
184
|
+
human decide.
|
|
185
|
+
- Cross-reference every claim against the actual code as `path:line`; do not assert
|
|
186
|
+
what the codebase does from memory.
|
|
187
|
+
- Never let anything unresolved silently vanish: if you cannot get an answer,
|
|
188
|
+
record it as an `assumed` decision so it surfaces as an open question.
|
|
189
|
+
- The human can stop anytime; the card always carries a stop affordance, so honor it.
|
|
190
|
+
|
|
191
|
+
### Asking - question cards
|
|
192
|
+
|
|
193
|
+
Post a structured question with `ask`.
|
|
194
|
+
Options are structured (a label, a description, an optional `recommended` flag), so
|
|
195
|
+
the card is passed as JSON - inline via `--json` or as a file path positional:
|
|
196
|
+
|
|
197
|
+
```
|
|
198
|
+
npx chamba@latest ask --json '{
|
|
199
|
+
"question": "How should an expired checkout session behave?",
|
|
200
|
+
"options": [
|
|
201
|
+
{"label": "Silent refresh", "description": "Start a new session, keep the cart, no interruption.", "recommended": true},
|
|
202
|
+
{"label": "Prompt to resume", "description": "Show a resume dialog before restoring the cart."},
|
|
203
|
+
{"label": "Hard reset", "description": "Discard the cart and start over."}
|
|
204
|
+
]
|
|
205
|
+
}'
|
|
206
|
+
```
|
|
207
|
+
|
|
208
|
+
Offer as many options as the question genuinely has (up to six); do not pad to a
|
|
209
|
+
number, and do not collapse real choices to fit.
|
|
210
|
+
You never add a "let me type my own" option or a "leave a note" option: the card
|
|
211
|
+
always shows a free-text custom-answer field and always lets the human annotate
|
|
212
|
+
their choice, with voice on both.
|
|
213
|
+
The answer returns as a normal message on your next `poll` - there is no separate
|
|
214
|
+
answer command - and `ask` fills in the card id for you.
|
|
215
|
+
|
|
216
|
+
### Recording decisions
|
|
217
|
+
|
|
218
|
+
Every material choice goes on the decision log, marked `confirmed` (the human chose
|
|
219
|
+
it) or `assumed` (you chose it provisionally on their behalf):
|
|
220
|
+
|
|
221
|
+
```
|
|
222
|
+
npx chamba@latest decision --status confirmed --summary "Expired sessions refresh silently, cart preserved"
|
|
223
|
+
npx chamba@latest decision --status assumed --summary "Guest checkout is in scope" --detail "Unconfirmed; revisit before finalizing"
|
|
224
|
+
```
|
|
225
|
+
|
|
226
|
+
`assumed` entries are the ones that surface as open questions on export, so record
|
|
227
|
+
them honestly rather than guessing silently.
|
|
228
|
+
|
|
229
|
+
### Building artifacts - draft, mock, diagram
|
|
230
|
+
|
|
231
|
+
Publish a draft, mock, or diagram from a file with `artifact`; the matching surface
|
|
232
|
+
tab renders it, annotatable like the app:
|
|
233
|
+
|
|
234
|
+
```
|
|
235
|
+
npx chamba@latest artifact --kind draft --name spec --file /abs/spec.md
|
|
236
|
+
npx chamba@latest artifact --kind mock --name checkout --file /abs/checkout.html
|
|
237
|
+
npx chamba@latest artifact --kind diagram --name flow --file /abs/flow.mmd
|
|
238
|
+
```
|
|
239
|
+
|
|
240
|
+
- `draft` is markdown (rendered), `mock` is HTML (served sandboxed with the
|
|
241
|
+
annotation layer injected), `diagram` is mermaid.
|
|
242
|
+
- Build the draft live: re-post the same `--kind draft --name <name>` as you write,
|
|
243
|
+
and its tab reloads to the new revision each time - this is how the spec builds in
|
|
244
|
+
front of the human.
|
|
245
|
+
- Keep one draft name (e.g. `spec`) as the canonical draft; it becomes `spec.md` on
|
|
246
|
+
export, and any other draft names land in `assets/`.
|
|
247
|
+
- Mocks and diagrams are annotated through the same select -> comment -> card flow as
|
|
248
|
+
the app tab; a batch of mock annotations arrives on `poll` just like app ones.
|
|
249
|
+
|
|
250
|
+
### Exporting the package
|
|
251
|
+
|
|
252
|
+
Nothing leaves `.chamba/` automatically.
|
|
253
|
+
When the spec is ready to be official, copy the self-contained package to a
|
|
254
|
+
destination the human names (usually under `docs/`):
|
|
255
|
+
|
|
256
|
+
```
|
|
257
|
+
npx chamba@latest export docs/checkout-spec
|
|
258
|
+
```
|
|
259
|
+
|
|
260
|
+
This writes `spec.md` (the canonical draft), `assets/` (mocks and diagrams), and
|
|
261
|
+
`decisions.md` (the log, grouped confirmed vs. assumed/open).
|
|
262
|
+
|
|
263
|
+
## Notes
|
|
264
|
+
|
|
265
|
+
- All commands talk to a local server that shares this container. Each project has
|
|
266
|
+
its own server on a port derived from its `.chamba` location, so you never set a
|
|
267
|
+
port by hand.
|
|
268
|
+
- Presence is automatic and honest: a parked `poll` shows the agent as "here"
|
|
269
|
+
(attending, waiting for input); the moment a poll returns carrying the human's
|
|
270
|
+
message and you go act on it, the browser shows "working"; a reply or your next
|
|
271
|
+
poll returns it to "here". It flips to "away" only after a long idle stretch with
|
|
272
|
+
no poll, or promptly when the `poll` process exits (killed or crashed).
|
|
273
|
+
- There is no channel from the browser back into your terminal: anything you print
|
|
274
|
+
there is invisible to the human, so never break the `poll` loop to talk to them -
|
|
275
|
+
keep it running for the whole life of the session. If the human wants you on a
|
|
276
|
+
session you are not polling, they resume it from their side: by running `chamba
|
|
277
|
+
attach <id>` in the terminal, or - when you are attending another session -
|
|
278
|
+
clicking "Activate this session" in the browser, which you pick up as a `· You
|
|
279
|
+
moved to another session` line and follow with `attach`.
|
|
280
|
+
- The server shuts itself down after a spell with no browser open and no parked
|
|
281
|
+
poll; the next `open`/`attach` starts a fresh one. Nothing sent is lost - it is
|
|
282
|
+
durable on disk and re-delivered when you next `poll`. To stop it deliberately
|
|
283
|
+
(for example before closing out the project), run `npx chamba@latest stop`.
|
|
284
|
+
- Past sessions stay readable: `npx chamba@latest attach <id>` reloads any session's
|
|
285
|
+
recent history.
|
|
@@ -0,0 +1 @@
|
|
|
1
|
+
import{g as p,r as u,d as a}from"./chunk-MOJQB5TN-DCKqdaDr.js";import{p as f}from"./chunk-JWPE2WC7-BjbBLYge.js";import{_ as n,l as o}from"./mermaid.core-bOV5iNX_.js";import{M as c,b as d}from"./cynefin-VYW2F7L2-7JQwpRwH.js";import"./index-BN-QUr5b.js";var v=d().RailroadAbnf.parser.LangiumParser,i=n(e=>{const r=e.alternatives.map(g);return r.length===1?r[0]:{type:"choice",alternatives:r}},"transformAlternation"),g=n(e=>{const r=e.elements.map(y);return r.length===1?r[0]:{type:"sequence",elements:r}},"transformConcatenation"),b=n(e=>{if(e.includes("*")){const[t,s]=e.split("*"),l=t?parseInt(t,10):0,m=s?parseInt(s,10):1/0;return{min:l,max:m}}const r=parseInt(e,10);return{min:r,max:r}},"parseRepeat"),y=n(e=>{const r=A(e.primary);if(!e.repeat)return r;const{min:t,max:s}=b(e.repeat);return t===0&&s===1?{type:"optional",element:r}:{type:"repetition",element:r,min:t,max:s}},"transformElement"),A=n(e=>{switch(e.$type){case"AbnfStringLiteral":return{type:"terminal",value:e.value};case"AbnfNumVal":return{type:"terminal",value:e.value};case"AbnfRuleName":return{type:"nonterminal",name:e.name};case"AbnfGroup":return i(e.element);case"AbnfOptionalGroup":return{type:"optional",element:i(e.element)};default:throw new Error(`Unsupported ABNF primary node: ${e.$type}`)}},"transformPrimary"),P=n(e=>({name:e.name,definition:i(e.definition)}),"transformRule"),h=n(e=>{f(e,a),e.title&&a.setTitle(e.title),e.rules.map(r=>a.addRule(P(r)))},"populateDb"),R={parse:n(e=>{a.clear(),o.debug("[ABNF Parser] Starting Langium parse");const r=v.parse(e);if(r.lexerErrors.length>0||r.parserErrors.length>0)throw new c(r);const t=r.value;o.debug("[ABNF Parser] Parsed rules:",t.rules.length),h(t),o.debug("[ABNF Parser] Parse complete")},"parse"),parser:{yy:a}},B={parser:R,db:a,renderer:u,styles:p};export{B as diagram};
|
|
@@ -0,0 +1 @@
|
|
|
1
|
+
import{Y as ln,$ as an,a0 as F,a1 as q,a2 as j,a3 as un,a4 as y,a5 as tn,a6 as J,a7 as _,a8 as rn,a9 as o,aa as on,ab as sn,ac as fn}from"./mermaid.core-bOV5iNX_.js";function cn(l){return l.innerRadius}function yn(l){return l.outerRadius}function gn(l){return l.startAngle}function dn(l){return l.endAngle}function mn(l){return l&&l.padAngle}function pn(l,h,I,D,v,A,z,a){var O=I-l,i=D-h,n=z-v,d=a-A,u=d*O-n*i;if(!(u*u<y))return u=(n*(h-A)-d*(l-v))/u,[l+u*O,h+u*i]}function U(l,h,I,D,v,A,z){var a=l-I,O=h-D,i=(z?A:-A)/J(a*a+O*O),n=i*O,d=-i*a,u=l+n,s=h+d,f=I+n,c=D+d,B=(u+f)/2,t=(s+c)/2,m=f-u,g=c-s,R=m*m+g*g,T=v-A,P=u*c-f*s,S=(g<0?-1:1)*J(on(0,T*T*R-P*P)),Y=(P*g-m*S)/R,$=(-P*m-g*S)/R,w=(P*g+m*S)/R,p=(-P*m+g*S)/R,x=Y-B,e=$-t,r=w-B,C=p-t;return x*x+e*e>r*r+C*C&&(Y=w,$=p),{cx:Y,cy:$,x01:-n,y01:-d,x11:Y*(v/T-1),y11:$*(v/T-1)}}function hn(){var l=cn,h=yn,I=j(0),D=null,v=gn,A=dn,z=mn,a=null,O=ln(i);function i(){var n,d,u=+l.apply(this,arguments),s=+h.apply(this,arguments),f=v.apply(this,arguments)-un,c=A.apply(this,arguments)-un,B=rn(c-f),t=c>f;if(a||(a=n=O()),s<u&&(d=s,s=u,u=d),!(s>y))a.moveTo(0,0);else if(B>tn-y)a.moveTo(s*F(f),s*q(f)),a.arc(0,0,s,f,c,!t),u>y&&(a.moveTo(u*F(c),u*q(c)),a.arc(0,0,u,c,f,t));else{var m=f,g=c,R=f,T=c,P=B,S=B,Y=z.apply(this,arguments)/2,$=Y>y&&(D?+D.apply(this,arguments):J(u*u+s*s)),w=_(rn(s-u)/2,+I.apply(this,arguments)),p=w,x=w,e,r;if($>y){var C=sn($/u*q(Y)),K=sn($/s*q(Y));(P-=C*2)>y?(C*=t?1:-1,R+=C,T-=C):(P=0,R=T=(f+c)/2),(S-=K*2)>y?(K*=t?1:-1,m+=K,g-=K):(S=0,m=g=(f+c)/2)}var G=s*F(m),H=s*q(m),L=u*F(T),M=u*q(T);if(w>y){var N=s*F(g),Q=s*q(g),V=u*F(R),W=u*q(R),E;if(B<an)if(E=pn(G,H,V,W,N,Q,L,M)){var X=G-E[0],Z=H-E[1],b=N-E[0],k=Q-E[1],nn=1/q(fn((X*b+Z*k)/(J(X*X+Z*Z)*J(b*b+k*k)))/2),en=J(E[0]*E[0]+E[1]*E[1]);p=_(w,(u-en)/(nn-1)),x=_(w,(s-en)/(nn+1))}else p=x=0}S>y?x>y?(e=U(V,W,G,H,s,x,t),r=U(N,Q,L,M,s,x,t),a.moveTo(e.cx+e.x01,e.cy+e.y01),x<w?a.arc(e.cx,e.cy,x,o(e.y01,e.x01),o(r.y01,r.x01),!t):(a.arc(e.cx,e.cy,x,o(e.y01,e.x01),o(e.y11,e.x11),!t),a.arc(0,0,s,o(e.cy+e.y11,e.cx+e.x11),o(r.cy+r.y11,r.cx+r.x11),!t),a.arc(r.cx,r.cy,x,o(r.y11,r.x11),o(r.y01,r.x01),!t))):(a.moveTo(G,H),a.arc(0,0,s,m,g,!t)):a.moveTo(G,H),!(u>y)||!(P>y)?a.lineTo(L,M):p>y?(e=U(L,M,N,Q,u,-p,t),r=U(G,H,V,W,u,-p,t),a.lineTo(e.cx+e.x01,e.cy+e.y01),p<w?a.arc(e.cx,e.cy,p,o(e.y01,e.x01),o(r.y01,r.x01),!t):(a.arc(e.cx,e.cy,p,o(e.y01,e.x01),o(e.y11,e.x11),!t),a.arc(0,0,u,o(e.cy+e.y11,e.cx+e.x11),o(r.cy+r.y11,r.cx+r.x11),t),a.arc(r.cx,r.cy,p,o(r.y11,r.x11),o(r.y01,r.x01),!t))):a.arc(0,0,u,T,R,t)}if(a.closePath(),n)return a=null,n+""||null}return i.centroid=function(){var n=(+l.apply(this,arguments)+ +h.apply(this,arguments))/2,d=(+v.apply(this,arguments)+ +A.apply(this,arguments))/2-an/2;return[F(d)*n,q(d)*n]},i.innerRadius=function(n){return arguments.length?(l=typeof n=="function"?n:j(+n),i):l},i.outerRadius=function(n){return arguments.length?(h=typeof n=="function"?n:j(+n),i):h},i.cornerRadius=function(n){return arguments.length?(I=typeof n=="function"?n:j(+n),i):I},i.padRadius=function(n){return arguments.length?(D=n==null?null:typeof n=="function"?n:j(+n),i):D},i.startAngle=function(n){return arguments.length?(v=typeof n=="function"?n:j(+n),i):v},i.endAngle=function(n){return arguments.length?(A=typeof n=="function"?n:j(+n),i):A},i.padAngle=function(n){return arguments.length?(z=typeof n=="function"?n:j(+n),i):z},i.context=function(n){return arguments.length?(a=n??null,i):a},i}export{hn as d};
|