create-snipara 2.1.1 → 2.2.1
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 +73 -3
- package/dist/index.js +1396 -363
- package/dist/managed-config.d.ts +19 -0
- package/dist/managed-config.js +86 -0
- package/dist/managed-toolchain.d.ts +38 -0
- package/dist/managed-toolchain.js +505 -0
- package/dist/source-connection.d.ts +12 -0
- package/dist/source-connection.js +199 -0
- package/package.json +4 -3
package/README.md
CHANGED
|
@@ -1,11 +1,27 @@
|
|
|
1
1
|
# create-snipara
|
|
2
2
|
|
|
3
|
-
**
|
|
3
|
+
**Set up local coding work or connect your project to Snipara context.**
|
|
4
4
|
|
|
5
5
|
`create-snipara` connects a local project to Snipara so AI agents can start
|
|
6
6
|
with project-owned context, reviewed memory, shared guidance, and optional code
|
|
7
7
|
impact tooling instead of starting cold every session.
|
|
8
8
|
|
|
9
|
+
## Choose your first step
|
|
10
|
+
|
|
11
|
+
| Goal | Command | Requirements |
|
|
12
|
+
| --- | --- | --- |
|
|
13
|
+
| Track and verify local coding work | `npx create-snipara@latest init --profile local-work --client codex` | Supported Node.js and Python; no Snipara account |
|
|
14
|
+
| Connect sourced project context | `npx create-snipara@latest` | Authorized Snipara project connection |
|
|
15
|
+
| Connect an existing self-hosted server | Use `--self-hosted` with its endpoint | Running server and operator credentials |
|
|
16
|
+
|
|
17
|
+
Use `--client claude-code` for Claude Code. Local work prepares compatible
|
|
18
|
+
Companion, Orchestrator and Sandbox tools. It does not install Docker or
|
|
19
|
+
dependency images, run tests or call a model. Hosted context is optional for
|
|
20
|
+
local work; add `--connect-context` when you want to set it up explicitly.
|
|
21
|
+
See [install profiles](#install-profiles) for the full contract.
|
|
22
|
+
|
|
23
|
+
## Connect project context
|
|
24
|
+
|
|
9
25
|
The shortest path is three moments: connect the folder your agent already uses,
|
|
10
26
|
let Snipara index its project context, then ask one question that only the
|
|
11
27
|
project can answer.
|
|
@@ -24,7 +40,7 @@ npx create-snipara@latest --self-hosted \
|
|
|
24
40
|
--client claude-code
|
|
25
41
|
```
|
|
26
42
|
|
|
27
|
-
Both modes aim to finish with the same visible proof:
|
|
43
|
+
Both context connection modes aim to finish with the same visible proof:
|
|
28
44
|
|
|
29
45
|
```text
|
|
30
46
|
✓ Endpoint connected
|
|
@@ -36,7 +52,7 @@ Both modes aim to finish with the same visible proof:
|
|
|
36
52
|
`create-snipara` is the single activation engine for the agent path. It detects
|
|
37
53
|
or asks where Snipara should run, writes the right MCP config, seeds a small
|
|
38
54
|
README/docs corpus, and automatically verifies a first project-grounded answer.
|
|
39
|
-
The default path is Cloud
|
|
55
|
+
The default context path is Cloud; the same
|
|
40
56
|
flow works with an existing self-hosted Snipara Server.
|
|
41
57
|
It is also the canonical activation engine behind editor setup docs: VS Code can
|
|
42
58
|
surface activation as a native command, Cursor can pair OpenVSX UI with Hosted
|
|
@@ -111,6 +127,60 @@ activation report or JSON summary.
|
|
|
111
127
|
|
|
112
128
|
## Install Profiles
|
|
113
129
|
|
|
130
|
+
The normal prompt offers **Context** (`hosted-only`) and **Local work**
|
|
131
|
+
(`local-work`). Advanced choices below remain available.
|
|
132
|
+
|
|
133
|
+
```sh
|
|
134
|
+
npx create-snipara@latest init --profile local-work --client codex
|
|
135
|
+
npx create-snipara@latest doctor
|
|
136
|
+
npx create-snipara@latest repair --profile local-work
|
|
137
|
+
npx create-snipara@latest toolchain status
|
|
138
|
+
npx create-snipara@latest toolchain rollback
|
|
139
|
+
```
|
|
140
|
+
|
|
141
|
+
Local work runs locally without a Snipara account or cloud subscription. If an
|
|
142
|
+
existing repository connection is authorized, its native broker automatically
|
|
143
|
+
reuses that context. A configured or pending connection alone is not proof of
|
|
144
|
+
authorization; disconnected users continue locally. To explicitly start optional
|
|
145
|
+
context onboarding, add `--connect-context`. This never becomes a prerequisite
|
|
146
|
+
for local tasks or validation, and a global API key does not select a project.
|
|
147
|
+
|
|
148
|
+
Local work prepares compatible private Companion, Orchestrator and Sandbox
|
|
149
|
+
versions, checks their versions and installed command hashes, then atomically
|
|
150
|
+
selects the completed bundle. It uses the existing Node/npm and Python runtimes;
|
|
151
|
+
Node.js must already be version 18+ and Python version 3.10+; incompatible
|
|
152
|
+
runtimes fail before virtual-environment creation or package installation. It
|
|
153
|
+
does not install an operating-system runtime, Docker, dependency images or a
|
|
154
|
+
model provider. Package preparation uses a private home and no provider keys.
|
|
155
|
+
Preparation failure keeps the prior active bundle and its failure receipt.
|
|
156
|
+
Repeated preparation verifies the current matching bundle; rollback checks the
|
|
157
|
+
previous bundle without resetting tasks, evidence, configuration or secrets.
|
|
158
|
+
Explicit repair can replace a changed owned bundle while retaining its original
|
|
159
|
+
files and a recovery reference. Foreign active pointers are refused. Interrupting
|
|
160
|
+
preparation stops and reaps its child before releasing installation ownership;
|
|
161
|
+
an unobserved cleanup keeps the lock for reconciliation.
|
|
162
|
+
|
|
163
|
+
The native connection starts the retained Companion `toolchain mcp` bootstrap;
|
|
164
|
+
each new session selects and pins the active bundle. Its configuration contains
|
|
165
|
+
no Snipara or provider keys. Existing source-bound `snipara-repository` connections
|
|
166
|
+
are preserved; local work does not add a direct hosted server alongside that
|
|
167
|
+
binding. Fresh local-work setup adds no hosted server, project binding, API-key
|
|
168
|
+
environment files or automatic upload. Explicit context setup retains the
|
|
169
|
+
existing project/auth flow and makes no automatic repository binding claim.
|
|
170
|
+
Installing components is
|
|
171
|
+
separate from connecting a project and observing a grounded first answer.
|
|
172
|
+
Both Claude's JSON and Codex's complete TOML are inspected before choosing this
|
|
173
|
+
path, with the canonical source helper validating the configured fingerprint
|
|
174
|
+
against the current repository or folder. Existing Codex inspection needs
|
|
175
|
+
Python 3.11+, or Python 3.10 with `tomli`; a missing parser produces an explicit
|
|
176
|
+
setup error. A source mismatch never falls back to another hosted project.
|
|
177
|
+
|
|
178
|
+
Codex setup validates the complete TOML with the prepared Python parser and
|
|
179
|
+
appends only an absent managed connection. Existing unrelated bytes stay intact.
|
|
180
|
+
Conflicting or malformed configuration is preserved and setup reports incomplete;
|
|
181
|
+
it is never replaced with a guessed configuration. Repair and upgrade remember
|
|
182
|
+
the local-work selection from existing activation/native configuration.
|
|
183
|
+
|
|
114
184
|
The CLI now works around explicit install profiles:
|
|
115
185
|
|
|
116
186
|
| Profile | What it installs | Best for |
|