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 +58 -0
- package/dist/index.js +1400 -368
- 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
|
@@ -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 |
|