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 CHANGED
@@ -1,11 +1,27 @@
1
1
  # create-snipara
2
2
 
3
- **One-command onboarding for Snipara Cloud or self-hosted Snipara Server.**
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 because it is the fastest first experience; the same
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 |