create-snipara 2.1.0 → 2.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 CHANGED
@@ -6,6 +6,10 @@
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
+ The shortest path is three moments: connect the folder your agent already uses,
10
+ let Snipara index its project context, then ask one question that only the
11
+ project can answer.
12
+
9
13
  ```bash
10
14
  npx create-snipara
11
15
  ```
@@ -107,6 +111,60 @@ activation report or JSON summary.
107
111
 
108
112
  ## Install Profiles
109
113
 
114
+ The normal prompt offers **Context** (`hosted-only`) and **Local work**
115
+ (`local-work`). Advanced choices below remain available.
116
+
117
+ ```sh
118
+ npx create-snipara@latest init --profile local-work --client codex
119
+ npx create-snipara@latest doctor
120
+ npx create-snipara@latest repair --profile local-work
121
+ npx create-snipara@latest toolchain status
122
+ npx create-snipara@latest toolchain rollback
123
+ ```
124
+
125
+ Local work runs locally without a Snipara account or cloud subscription. If an
126
+ existing repository connection is authorized, its native broker automatically
127
+ reuses that context. A configured or pending connection alone is not proof of
128
+ authorization; disconnected users continue locally. To explicitly start optional
129
+ context onboarding, add `--connect-context`. This never becomes a prerequisite
130
+ for local tasks or validation, and a global API key does not select a project.
131
+
132
+ Local work prepares compatible private Companion, Orchestrator and Sandbox
133
+ versions, checks their versions and installed command hashes, then atomically
134
+ selects the completed bundle. It uses the existing Node/npm and Python runtimes;
135
+ Node.js must already be version 18+ and Python version 3.10+; incompatible
136
+ runtimes fail before virtual-environment creation or package installation. It
137
+ does not install an operating-system runtime, Docker, dependency images or a
138
+ model provider. Package preparation uses a private home and no provider keys.
139
+ Preparation failure keeps the prior active bundle and its failure receipt.
140
+ Repeated preparation verifies the current matching bundle; rollback checks the
141
+ previous bundle without resetting tasks, evidence, configuration or secrets.
142
+ Explicit repair can replace a changed owned bundle while retaining its original
143
+ files and a recovery reference. Foreign active pointers are refused. Interrupting
144
+ preparation stops and reaps its child before releasing installation ownership;
145
+ an unobserved cleanup keeps the lock for reconciliation.
146
+
147
+ The native connection starts the retained Companion `toolchain mcp` bootstrap;
148
+ each new session selects and pins the active bundle. Its configuration contains
149
+ no Snipara or provider keys. Existing source-bound `snipara-repository` connections
150
+ are preserved; local work does not add a direct hosted server alongside that
151
+ binding. Fresh local-work setup adds no hosted server, project binding, API-key
152
+ environment files or automatic upload. Explicit context setup retains the
153
+ existing project/auth flow and makes no automatic repository binding claim.
154
+ Installing components is
155
+ separate from connecting a project and observing a grounded first answer.
156
+ Both Claude's JSON and Codex's complete TOML are inspected before choosing this
157
+ path, with the canonical source helper validating the configured fingerprint
158
+ against the current repository or folder. Existing Codex inspection needs
159
+ Python 3.11+, or Python 3.10 with `tomli`; a missing parser produces an explicit
160
+ setup error. A source mismatch never falls back to another hosted project.
161
+
162
+ Codex setup validates the complete TOML with the prepared Python parser and
163
+ appends only an absent managed connection. Existing unrelated bytes stay intact.
164
+ Conflicting or malformed configuration is preserved and setup reports incomplete;
165
+ it is never replaced with a guessed configuration. Repair and upgrade remember
166
+ the local-work selection from existing activation/native configuration.
167
+
110
168
  The CLI now works around explicit install profiles:
111
169
 
112
170
  | Profile | What it installs | Best for |