@functional-systems/srcx 0.1.0-dev.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/CHANGELOG.md +20 -0
- package/CONTRIBUTING.md +54 -0
- package/DESIGN.md +1057 -0
- package/LICENSE +202 -0
- package/README.md +209 -0
- package/RELEASING.md +137 -0
- package/VALIDATION.md +181 -0
- package/dist/build.d.ts +94 -0
- package/dist/build.js +433 -0
- package/dist/build.js.map +1 -0
- package/dist/chunk.d.ts +30 -0
- package/dist/chunk.js +296 -0
- package/dist/chunk.js.map +1 -0
- package/dist/cli.d.ts +2 -0
- package/dist/cli.js +276 -0
- package/dist/cli.js.map +1 -0
- package/dist/common.d.ts +17 -0
- package/dist/common.js +74 -0
- package/dist/common.js.map +1 -0
- package/dist/git.d.ts +38 -0
- package/dist/git.js +224 -0
- package/dist/git.js.map +1 -0
- package/dist/publish.d.ts +60 -0
- package/dist/publish.js +341 -0
- package/dist/publish.js.map +1 -0
- package/dist/releases.d.ts +8 -0
- package/dist/releases.js +79 -0
- package/dist/releases.js.map +1 -0
- package/dist/remote.d.ts +53 -0
- package/dist/remote.js +136 -0
- package/dist/remote.js.map +1 -0
- package/dist/repository.d.ts +29 -0
- package/dist/repository.js +180 -0
- package/dist/repository.js.map +1 -0
- package/dist/search.d.ts +46 -0
- package/dist/search.js +181 -0
- package/dist/search.js.map +1 -0
- package/dist/settings.d.ts +10 -0
- package/dist/settings.js +35 -0
- package/dist/settings.js.map +1 -0
- package/package.json +58 -0
- package/src/build.ts +587 -0
- package/src/chunk.ts +328 -0
- package/src/cli.ts +366 -0
- package/src/common.ts +71 -0
- package/src/git.ts +286 -0
- package/src/publish.ts +487 -0
- package/src/releases.ts +108 -0
- package/src/remote.ts +230 -0
- package/src/repository.ts +306 -0
- package/src/search.ts +282 -0
- package/src/settings.ts +59 -0
package/LICENSE
ADDED
|
@@ -0,0 +1,202 @@
|
|
|
1
|
+
|
|
2
|
+
Apache License
|
|
3
|
+
Version 2.0, January 2004
|
|
4
|
+
http://www.apache.org/licenses/
|
|
5
|
+
|
|
6
|
+
TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
|
|
7
|
+
|
|
8
|
+
1. Definitions.
|
|
9
|
+
|
|
10
|
+
"License" shall mean the terms and conditions for use, reproduction,
|
|
11
|
+
and distribution as defined by Sections 1 through 9 of this document.
|
|
12
|
+
|
|
13
|
+
"Licensor" shall mean the copyright owner or entity authorized by
|
|
14
|
+
the copyright owner that is granting the License.
|
|
15
|
+
|
|
16
|
+
"Legal Entity" shall mean the union of the acting entity and all
|
|
17
|
+
other entities that control, are controlled by, or are under common
|
|
18
|
+
control with that entity. For the purposes of this definition,
|
|
19
|
+
"control" means (i) the power, direct or indirect, to cause the
|
|
20
|
+
direction or management of such entity, whether by contract or
|
|
21
|
+
otherwise, or (ii) ownership of fifty percent (50%) or more of the
|
|
22
|
+
outstanding shares, or (iii) beneficial ownership of such entity.
|
|
23
|
+
|
|
24
|
+
"You" (or "Your") shall mean an individual or Legal Entity
|
|
25
|
+
exercising permissions granted by this License.
|
|
26
|
+
|
|
27
|
+
"Source" form shall mean the preferred form for making modifications,
|
|
28
|
+
including but not limited to software source code, documentation
|
|
29
|
+
source, and configuration files.
|
|
30
|
+
|
|
31
|
+
"Object" form shall mean any form resulting from mechanical
|
|
32
|
+
transformation or translation of a Source form, including but
|
|
33
|
+
not limited to compiled object code, generated documentation,
|
|
34
|
+
and conversions to other media types.
|
|
35
|
+
|
|
36
|
+
"Work" shall mean the work of authorship, whether in Source or
|
|
37
|
+
Object form, made available under the License, as indicated by a
|
|
38
|
+
copyright notice that is included in or attached to the work
|
|
39
|
+
(an example is provided in the Appendix below).
|
|
40
|
+
|
|
41
|
+
"Derivative Works" shall mean any work, whether in Source or Object
|
|
42
|
+
form, that is based on (or derived from) the Work and for which the
|
|
43
|
+
editorial revisions, annotations, elaborations, or other modifications
|
|
44
|
+
represent, as a whole, an original work of authorship. For the purposes
|
|
45
|
+
of this License, Derivative Works shall not include works that remain
|
|
46
|
+
separable from, or merely link (or bind by name) to the interfaces of,
|
|
47
|
+
the Work and Derivative Works thereof.
|
|
48
|
+
|
|
49
|
+
"Contribution" shall mean any work of authorship, including
|
|
50
|
+
the original version of the Work and any modifications or additions
|
|
51
|
+
to that Work or Derivative Works thereof, that is intentionally
|
|
52
|
+
submitted to Licensor for inclusion in the Work by the copyright owner
|
|
53
|
+
or by an individual or Legal Entity authorized to submit on behalf of
|
|
54
|
+
the copyright owner. For the purposes of this definition, "submitted"
|
|
55
|
+
means any form of electronic, verbal, or written communication sent
|
|
56
|
+
to the Licensor or its representatives, including but not limited to
|
|
57
|
+
communication on electronic mailing lists, source code control systems,
|
|
58
|
+
and issue tracking systems that are managed by, or on behalf of, the
|
|
59
|
+
Licensor for the purpose of discussing and improving the Work, but
|
|
60
|
+
excluding communication that is conspicuously marked or otherwise
|
|
61
|
+
designated in writing by the copyright owner as "Not a Contribution."
|
|
62
|
+
|
|
63
|
+
"Contributor" shall mean Licensor and any individual or Legal Entity
|
|
64
|
+
on behalf of whom a Contribution has been received by Licensor and
|
|
65
|
+
subsequently incorporated within the Work.
|
|
66
|
+
|
|
67
|
+
2. Grant of Copyright License. Subject to the terms and conditions of
|
|
68
|
+
this License, each Contributor hereby grants to You a perpetual,
|
|
69
|
+
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
|
|
70
|
+
copyright license to reproduce, prepare Derivative Works of,
|
|
71
|
+
publicly display, publicly perform, sublicense, and distribute the
|
|
72
|
+
Work and such Derivative Works in Source or Object form.
|
|
73
|
+
|
|
74
|
+
3. Grant of Patent License. Subject to the terms and conditions of
|
|
75
|
+
this License, each Contributor hereby grants to You a perpetual,
|
|
76
|
+
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
|
|
77
|
+
(except as stated in this section) patent license to make, have made,
|
|
78
|
+
use, offer to sell, sell, import, and otherwise transfer the Work,
|
|
79
|
+
where such license applies only to those patent claims licensable
|
|
80
|
+
by such Contributor that are necessarily infringed by their
|
|
81
|
+
Contribution(s) alone or by combination of their Contribution(s)
|
|
82
|
+
with the Work to which such Contribution(s) was submitted. If You
|
|
83
|
+
institute patent litigation against any entity (including a
|
|
84
|
+
cross-claim or counterclaim in a lawsuit) alleging that the Work
|
|
85
|
+
or a Contribution incorporated within the Work constitutes direct
|
|
86
|
+
or contributory patent infringement, then any patent licenses
|
|
87
|
+
granted to You under this License for that Work shall terminate
|
|
88
|
+
as of the date such litigation is filed.
|
|
89
|
+
|
|
90
|
+
4. Redistribution. You may reproduce and distribute copies of the
|
|
91
|
+
Work or Derivative Works thereof in any medium, with or without
|
|
92
|
+
modifications, and in Source or Object form, provided that You
|
|
93
|
+
meet the following conditions:
|
|
94
|
+
|
|
95
|
+
(a) You must give any other recipients of the Work or
|
|
96
|
+
Derivative Works a copy of this License; and
|
|
97
|
+
|
|
98
|
+
(b) You must cause any modified files to carry prominent notices
|
|
99
|
+
stating that You changed the files; and
|
|
100
|
+
|
|
101
|
+
(c) You must retain, in the Source form of any Derivative Works
|
|
102
|
+
that You distribute, all copyright, patent, trademark, and
|
|
103
|
+
attribution notices from the Source form of the Work,
|
|
104
|
+
excluding those notices that do not pertain to any part of
|
|
105
|
+
the Derivative Works; and
|
|
106
|
+
|
|
107
|
+
(d) If the Work includes a "NOTICE" text file as part of its
|
|
108
|
+
distribution, then any Derivative Works that You distribute must
|
|
109
|
+
include a readable copy of the attribution notices contained
|
|
110
|
+
within such NOTICE file, excluding those notices that do not
|
|
111
|
+
pertain to any part of the Derivative Works, in at least one
|
|
112
|
+
of the following places: within a NOTICE text file distributed
|
|
113
|
+
as part of the Derivative Works; within the Source form or
|
|
114
|
+
documentation, if provided along with the Derivative Works; or,
|
|
115
|
+
within a display generated by the Derivative Works, if and
|
|
116
|
+
wherever such third-party notices normally appear. The contents
|
|
117
|
+
of the NOTICE file are for informational purposes only and
|
|
118
|
+
do not modify the License. You may add Your own attribution
|
|
119
|
+
notices within Derivative Works that You distribute, alongside
|
|
120
|
+
or as an addendum to the NOTICE text from the Work, provided
|
|
121
|
+
that such additional attribution notices cannot be construed
|
|
122
|
+
as modifying the License.
|
|
123
|
+
|
|
124
|
+
You may add Your own copyright statement to Your modifications and
|
|
125
|
+
may provide additional or different license terms and conditions
|
|
126
|
+
for use, reproduction, or distribution of Your modifications, or
|
|
127
|
+
for any such Derivative Works as a whole, provided Your use,
|
|
128
|
+
reproduction, and distribution of the Work otherwise complies with
|
|
129
|
+
the conditions stated in this License.
|
|
130
|
+
|
|
131
|
+
5. Submission of Contributions. Unless You explicitly state otherwise,
|
|
132
|
+
any Contribution intentionally submitted for inclusion in the Work
|
|
133
|
+
by You to the Licensor shall be under the terms and conditions of
|
|
134
|
+
this License, without any additional terms or conditions.
|
|
135
|
+
Notwithstanding the above, nothing herein shall supersede or modify
|
|
136
|
+
the terms of any separate license agreement you may have executed
|
|
137
|
+
with Licensor regarding such Contributions.
|
|
138
|
+
|
|
139
|
+
6. Trademarks. This License does not grant permission to use the trade
|
|
140
|
+
names, trademarks, service marks, or product names of the Licensor,
|
|
141
|
+
except as required for reasonable and customary use in describing the
|
|
142
|
+
origin of the Work and reproducing the content of the NOTICE file.
|
|
143
|
+
|
|
144
|
+
7. Disclaimer of Warranty. Unless required by applicable law or
|
|
145
|
+
agreed to in writing, Licensor provides the Work (and each
|
|
146
|
+
Contributor provides its Contributions) on an "AS IS" BASIS,
|
|
147
|
+
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
|
|
148
|
+
implied, including, without limitation, any warranties or conditions
|
|
149
|
+
of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
|
|
150
|
+
PARTICULAR PURPOSE. You are solely responsible for determining the
|
|
151
|
+
appropriateness of using or redistributing the Work and assume any
|
|
152
|
+
risks associated with Your exercise of permissions under this License.
|
|
153
|
+
|
|
154
|
+
8. Limitation of Liability. In no event and under no legal theory,
|
|
155
|
+
whether in tort (including negligence), contract, or otherwise,
|
|
156
|
+
unless required by applicable law (such as deliberate and grossly
|
|
157
|
+
negligent acts) or agreed to in writing, shall any Contributor be
|
|
158
|
+
liable to You for damages, including any direct, indirect, special,
|
|
159
|
+
incidental, or consequential damages of any character arising as a
|
|
160
|
+
result of this License or out of the use or inability to use the
|
|
161
|
+
Work (including but not limited to damages for loss of goodwill,
|
|
162
|
+
work stoppage, computer failure or malfunction, or any and all
|
|
163
|
+
other commercial damages or losses), even if such Contributor
|
|
164
|
+
has been advised of the possibility of such damages.
|
|
165
|
+
|
|
166
|
+
9. Accepting Warranty or Additional Liability. While redistributing
|
|
167
|
+
the Work or Derivative Works thereof, You may choose to offer,
|
|
168
|
+
and charge a fee for, acceptance of support, warranty, indemnity,
|
|
169
|
+
or other liability obligations and/or rights consistent with this
|
|
170
|
+
License. However, in accepting such obligations, You may act only
|
|
171
|
+
on Your own behalf and on Your sole responsibility, not on behalf
|
|
172
|
+
of any other Contributor, and only if You agree to indemnify,
|
|
173
|
+
defend, and hold each Contributor harmless for any liability
|
|
174
|
+
incurred by, or claims asserted against, such Contributor by reason
|
|
175
|
+
of your accepting any such warranty or additional liability.
|
|
176
|
+
|
|
177
|
+
END OF TERMS AND CONDITIONS
|
|
178
|
+
|
|
179
|
+
APPENDIX: How to apply the Apache License to your work.
|
|
180
|
+
|
|
181
|
+
To apply the Apache License to your work, attach the following
|
|
182
|
+
boilerplate notice, with the fields enclosed by brackets "[]"
|
|
183
|
+
replaced with your own identifying information. (Don't include
|
|
184
|
+
the brackets!) The text should be enclosed in the appropriate
|
|
185
|
+
comment syntax for the file format. We also recommend that a
|
|
186
|
+
file or class name and description of purpose be included on the
|
|
187
|
+
same "printed page" as the copyright notice for easier
|
|
188
|
+
identification within third-party archives.
|
|
189
|
+
|
|
190
|
+
Copyright [yyyy] [name of copyright owner]
|
|
191
|
+
|
|
192
|
+
Licensed under the Apache License, Version 2.0 (the "License");
|
|
193
|
+
you may not use this file except in compliance with the License.
|
|
194
|
+
You may obtain a copy of the License at
|
|
195
|
+
|
|
196
|
+
http://www.apache.org/licenses/LICENSE-2.0
|
|
197
|
+
|
|
198
|
+
Unless required by applicable law or agreed to in writing, software
|
|
199
|
+
distributed under the License is distributed on an "AS IS" BASIS,
|
|
200
|
+
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
201
|
+
See the License for the specific language governing permissions and
|
|
202
|
+
limitations under the License.
|
package/README.md
ADDED
|
@@ -0,0 +1,209 @@
|
|
|
1
|
+
# srcx
|
|
2
|
+
|
|
3
|
+
Version-aware code search on LambdaDB. Import a committed Git tree, search its
|
|
4
|
+
chunks, and read exact source pinned to a validated immutable version.
|
|
5
|
+
|
|
6
|
+
This is an experimental development CLI. Local fixture, fault-injection, SDK transport,
|
|
7
|
+
and opt-in live acceptance checks are available. The npm package is prepared for
|
|
8
|
+
publication but remains unpublished. See [VALIDATION.md](VALIDATION.md) for the latest observed results and
|
|
9
|
+
remaining scope, and [DESIGN.md](DESIGN.md) for the full design.
|
|
10
|
+
|
|
11
|
+
## Run locally
|
|
12
|
+
|
|
13
|
+
Requires Node.js 22.14+ and Git. The initial preset uses lexical search with
|
|
14
|
+
`embedding=none`; no embedding account or paid API is needed.
|
|
15
|
+
|
|
16
|
+
```sh
|
|
17
|
+
npm ci --ignore-scripts
|
|
18
|
+
npm test
|
|
19
|
+
npm run demo
|
|
20
|
+
node dist/cli.js --help
|
|
21
|
+
```
|
|
22
|
+
|
|
23
|
+
`npm run demo` creates a synthetic two-commit Git repository and exercises the
|
|
24
|
+
publication/search/read workflow through the internal fault-injection store.
|
|
25
|
+
It writes `.srcx/demo-report.json`, including paths to retained local build
|
|
26
|
+
artifacts. It does not contact LambdaDB. The model's lexical matching is a test
|
|
27
|
+
convenience, not a Lucene implementation or a relevance benchmark.
|
|
28
|
+
|
|
29
|
+
All commands return JSON, except help and errors. Use `node dist/cli.js` in this
|
|
30
|
+
checkout; `srcx` is the configured executable name for future distribution.
|
|
31
|
+
|
|
32
|
+
For development branches, CI, and installed-package checks, see
|
|
33
|
+
[CONTRIBUTING.md](CONTRIBUTING.md). Version channels, first-publication steps, and
|
|
34
|
+
the initially disabled npm automation are documented in [RELEASING.md](RELEASING.md).
|
|
35
|
+
The project is licensed under [Apache-2.0](LICENSE).
|
|
36
|
+
|
|
37
|
+
## Preview a committed version without credentials
|
|
38
|
+
|
|
39
|
+
```sh
|
|
40
|
+
node dist/cli.js import --path /path/to/repo --ref main --dry-run \
|
|
41
|
+
--output /tmp/srcx-build-a
|
|
42
|
+
|
|
43
|
+
# Compare a second selected commit with the first artifact.
|
|
44
|
+
node dist/cli.js import --path /path/to/repo --ref <full-commit-B> --dry-run \
|
|
45
|
+
--previous /tmp/srcx-build-a --output /tmp/srcx-build-b
|
|
46
|
+
```
|
|
47
|
+
|
|
48
|
+
The output directory must be new and its parent must exist. The command resolves
|
|
49
|
+
the ref once, reads Git tree/blob objects, and ignores working-tree edits. Local
|
|
50
|
+
branches, lightweight/annotated commit tags, and commit OIDs are accepted. Branch
|
|
51
|
+
and tag names that collide require `refs/heads/...` or `refs/tags/...`. No automatic
|
|
52
|
+
fetch, history replay, or revision expressions are supported.
|
|
53
|
+
|
|
54
|
+
Each artifact contains `build.json` (inventory, configuration, counts, hashes,
|
|
55
|
+
change/deletion plan) and `records.jsonl` (exact file records and retrieval chunks).
|
|
56
|
+
Artifacts contain source code; keep them with the same access policy as the repo.
|
|
57
|
+
Every tree entry is accounted for, including explicit exclusions for symlinks,
|
|
58
|
+
submodules, LFS pointers, dependencies/build output, binary/invalid UTF-8 data,
|
|
59
|
+
invalid UTF-8 paths, and files above 1 MiB. Excluded paths are preserved losslessly
|
|
60
|
+
in `pathBase64`.
|
|
61
|
+
|
|
62
|
+
Java, TypeScript/TSX, and JavaScript use pinned Tree-sitter WASM grammars. Markdown
|
|
63
|
+
uses heading/paragraph/fence boundaries; configuration text uses section/line
|
|
64
|
+
boundaries. Parse errors and unsupported languages use recorded text fallback.
|
|
65
|
+
Chunks cover the exact source bytes, carry one-based line ranges, target 800 tokens,
|
|
66
|
+
and stay below 1,500 tokens including path/symbol context. The internal window
|
|
67
|
+
baseline is available to the test/build API, not as a public storage backend.
|
|
68
|
+
|
|
69
|
+
## Explicit live acceptance run
|
|
70
|
+
|
|
71
|
+
The live harness accepts `LAMBDADB_BASE_URL`, `LAMBDADB_PROJECT_NAME`, and
|
|
72
|
+
`LAMBDADB_PROJECT_API_KEY` from your ignored `.env.local` file:
|
|
73
|
+
|
|
74
|
+
```sh
|
|
75
|
+
npm run test:live
|
|
76
|
+
# Increase the per-version wait deadline if the service indexes slowly.
|
|
77
|
+
SRCX_LIVE_TIMEOUT_MS=300000 npm run test:live
|
|
78
|
+
```
|
|
79
|
+
|
|
80
|
+
Node explicitly loads the env file for this command. The application does not
|
|
81
|
+
implicitly source repository env files or save the key. The harness uses only its
|
|
82
|
+
synthetic Git fixture, creates one Collection with test metadata, and retains the
|
|
83
|
+
remote resources, local retry journals, and `.srcx/live/report.json` for review.
|
|
84
|
+
It saves connection settings under `.srcx/live/config.json` and keeps its state
|
|
85
|
+
separate under `.srcx/live/state`. Rerunning resumes the saved synthetic run and
|
|
86
|
+
refuses to reuse it against a different destination.
|
|
87
|
+
|
|
88
|
+
## Connected workflow
|
|
89
|
+
|
|
90
|
+
These commands create and write LambdaDB resources. Select an approved project
|
|
91
|
+
and source scope before running them. Start live validation with the synthetic
|
|
92
|
+
fixture, not a production repository.
|
|
93
|
+
|
|
94
|
+
```sh
|
|
95
|
+
# Supply LAMBDADB_API_KEY through your shell or secret manager.
|
|
96
|
+
node dist/cli.js configure --endpoint https://api.lambdadb.ai --project <project>
|
|
97
|
+
node dist/cli.js doctor
|
|
98
|
+
node dist/cli.js repo add --path /path/to/repo \
|
|
99
|
+
--description "Repository source, tests, and documentation for code search." \
|
|
100
|
+
--tag team=search
|
|
101
|
+
node dist/cli.js repo list
|
|
102
|
+
node dist/cli.js repo show --repo <name>
|
|
103
|
+
|
|
104
|
+
# Import the exact artifact reviewed in the credential-free preview.
|
|
105
|
+
node dist/cli.js import --repo <name> --artifact /tmp/srcx-build-a
|
|
106
|
+
node dist/cli.js versions --repo <name>
|
|
107
|
+
node dist/cli.js search --repo <name> --version <full-commit-A> --query retry
|
|
108
|
+
node dist/cli.js read --result <result-id> --context 20
|
|
109
|
+
node dist/cli.js read --result <result-id> --full-file
|
|
110
|
+
node dist/cli.js read --repo <name> --version <full-commit-A> \
|
|
111
|
+
--path src/example.ts --lines 10:30
|
|
112
|
+
|
|
113
|
+
node dist/cli.js import --repo <name> --artifact /tmp/srcx-build-b
|
|
114
|
+
# An old A result still reads A after B is published.
|
|
115
|
+
node dist/cli.js read --result <result-id> --full-file
|
|
116
|
+
|
|
117
|
+
node dist/cli.js git sync-tags --repo <name>
|
|
118
|
+
node dist/cli.js resolve --repo <name> --ref v1.0.0
|
|
119
|
+
```
|
|
120
|
+
|
|
121
|
+
`doctor` checks authentication and Collection read access, not write permission
|
|
122
|
+
or indexing/query readiness. `configure --api-key-env NAME` selects another
|
|
123
|
+
credential environment variable; only its name is stored. Endpoint/project changes
|
|
124
|
+
cannot silently redirect result handles or retry journals.
|
|
125
|
+
|
|
126
|
+
Collection descriptions and metadata labels are used for repository context.
|
|
127
|
+
Discovery reads LambdaDB Collections and main-Branch descriptors, not a local
|
|
128
|
+
repository registry. Short names must be unique; otherwise use the complete source
|
|
129
|
+
identity or Collection name. Registration normalizes the selected Git remote;
|
|
130
|
+
`origin` is default. Use `--remote upstream` explicitly when needed. Repositories
|
|
131
|
+
without remotes receive a persistent local source identity. Repeated registration
|
|
132
|
+
preserves existing descriptions/labels and attaches the local checkout.
|
|
133
|
+
|
|
134
|
+
Search is literal analyzed lexical text, restricted to `kind=chunk`. Optional
|
|
135
|
+
`--path` and `--language` filters are exact keyword filters. `--limit` is 1–100.
|
|
136
|
+
Search results include a durable local `resultId`, commit, immutable Tag/Snapshot,
|
|
137
|
+
path, lines, and citation. Reads verify the original content hash and refuse
|
|
138
|
+
missing/recreated Tags. A direct path read defaults to the whole file; line ranges
|
|
139
|
+
are one-based and inclusive.
|
|
140
|
+
|
|
141
|
+
## Publication and recovery
|
|
142
|
+
|
|
143
|
+
The control Branch `main` holds descriptors/version summaries. `checkpoint-empty`
|
|
144
|
+
is forked before any control write. Each import uses a new `work-*` Branch,
|
|
145
|
+
optionally forked from the last locally retained, remotely validated writer
|
|
146
|
+
baseline. Writers are frozen after publication. A fresh local state can start a
|
|
147
|
+
full import from `checkpoint-empty`; source data is never forked from a Tag.
|
|
148
|
+
|
|
149
|
+
The importer deletes obsolete IDs, upserts changed records and inventory parts in
|
|
150
|
+
bounded sequential requests, then sends `__manifest__` **alone** after every prior
|
|
151
|
+
ACK. It polls the writer with `consistentRead=false`, creates a unique candidate
|
|
152
|
+
Tag, and checks its marker, complete document IDs/hashes, source coverage, and a
|
|
153
|
+
representative lexical query. Only a validated candidate is copied to the canonical
|
|
154
|
+
`ver-*` Tag and recorded as published. Full candidate validation protects against
|
|
155
|
+
an early/stale snapshot even after the marker is observed.
|
|
156
|
+
|
|
157
|
+
A per-Collection local lock and durable `pending.json` journal prevent another
|
|
158
|
+
commit from overwriting a partial attempt. Only one importing host is supported.
|
|
159
|
+
After a timeout or unknown write result, retain the artifacts and journal:
|
|
160
|
+
|
|
161
|
+
```sh
|
|
162
|
+
node dist/cli.js import --repo <name> --artifact /path/from/pending.json \
|
|
163
|
+
--resume --timeout 180
|
|
164
|
+
```
|
|
165
|
+
|
|
166
|
+
A write-stage resume replays the same explicit obsolete IDs and replacements under
|
|
167
|
+
exclusive ownership. It needs the pending build's artifact and journal, but not
|
|
168
|
+
the previous published build's local artifact: the journal identifies the immutable
|
|
169
|
+
remote baseline. Build validation checks that the full Git commit OID, repository,
|
|
170
|
+
and configuration agree with the build ID before publication.
|
|
171
|
+
A waiting-stage resume does not rewrite the corpus. SDK
|
|
172
|
+
transparent retries are disabled. If the process crashes while holding
|
|
173
|
+
`writer.lock`, first verify the recorded process is no longer importing, then
|
|
174
|
+
remove that specific lock directory. Do not delete `pending.json` to force a new
|
|
175
|
+
commit over an uncertain workspace. Unexpected baselines fail closed; automatic
|
|
176
|
+
recovery to a new workspace and resource cleanup are not implemented yet.
|
|
177
|
+
|
|
178
|
+
Git tag synchronization observes local `refs/tags/*` only. Multiple Git tags for
|
|
179
|
+
one commit create separate `rel-*` Aliases targeting the same published Tag.
|
|
180
|
+
An unimported/moved target is pending; the previously pinned version remains usable
|
|
181
|
+
but does not masquerade as the current release. Run `git sync-tags` again after
|
|
182
|
+
importing the target. Absence in a local clone never deletes a remote Alias.
|
|
183
|
+
For search and resolve, a synchronized Git tag name takes precedence over a commit
|
|
184
|
+
prefix, matching Git import's tag-before-OID rule. A pending tag fails explicitly
|
|
185
|
+
instead of falling back to a matching commit prefix. Use `refs/tags/<name>` to
|
|
186
|
+
select a Git tag explicitly.
|
|
187
|
+
Explicit authoritative pruning and persistent tracked-branch synchronization are
|
|
188
|
+
follow-up work; no full history import is required.
|
|
189
|
+
|
|
190
|
+
## State and implementation map
|
|
191
|
+
|
|
192
|
+
Configuration: `$XDG_CONFIG_HOME/srcx/config.json` or `~/.config/srcx/config.json`.
|
|
193
|
+
State: `$XDG_STATE_HOME/srcx` or `~/.local/state/srcx`. Test/isolated overrides are
|
|
194
|
+
`SRCX_CONFIG` and `SRCX_STATE_DIR`. State includes checkout attachments, local-source
|
|
195
|
+
IDs, build artifacts, publication journals, and result handles. Remote repository
|
|
196
|
+
and publication records remain authoritative.
|
|
197
|
+
|
|
198
|
+
| Files | Responsibility |
|
|
199
|
+
| ------------------------------------------------------------------------------------ | ----------------------------------------------------------------------- |
|
|
200
|
+
| [src/cli.ts](src/cli.ts), [src/settings.ts](src/settings.ts) | CLI and secret-reference-only configuration |
|
|
201
|
+
| [src/git.ts](src/git.ts), [src/chunk.ts](src/chunk.ts), [src/build.ts](src/build.ts) | Git object inventory, bounded chunks, reproducible artifacts |
|
|
202
|
+
| [src/remote.ts](src/remote.ts), [src/repository.ts](src/repository.ts) | LambdaDB SDK boundary, provisioning, remote discovery |
|
|
203
|
+
| [src/publish.ts](src/publish.ts) | Journal, ordering barrier, immutable validation/publication |
|
|
204
|
+
| [src/search.ts](src/search.ts), [src/releases.ts](src/releases.ts) | Pinned search/read and Git-tag Aliases |
|
|
205
|
+
| [src/common.ts](src/common.ts) | Canonical hashing and atomic local JSON writes |
|
|
206
|
+
| [test/](test/), [scripts/demo.mjs](scripts/demo.mjs) | Local fixtures, fault injection, SDK loopback contract, repeatable demo |
|
|
207
|
+
|
|
208
|
+
`npm run typecheck`, `npm test`, and `npm run format:check` are the local checks.
|
|
209
|
+
See the validation record before treating these checks as live-service evidence.
|
package/RELEASING.md
ADDED
|
@@ -0,0 +1,137 @@
|
|
|
1
|
+
# Releasing srcx
|
|
2
|
+
|
|
3
|
+
## Current state
|
|
4
|
+
|
|
5
|
+
The source is prepared as `@functional-systems/srcx@0.1.0-dev.1` under Apache-2.0.
|
|
6
|
+
It has not been published to npm. `private: false` permits a reviewed first
|
|
7
|
+
publication; it does not establish registry availability or distribution readiness.
|
|
8
|
+
`NPM_DEV_PUBLISH_ENABLED` is initially `false`. No stable/rc release or Homebrew
|
|
9
|
+
formula has been published. Local/live application evidence is in
|
|
10
|
+
[VALIDATION.md](VALIDATION.md); it is separate from package publication evidence.
|
|
11
|
+
|
|
12
|
+
This workflow follows [LambdaDB CLI](https://github.com/lambdadb/lambdadb-cli/blob/develop/RELEASING.md).
|
|
13
|
+
The repository keeps Prettier plus strict TypeScript checks as its existing lint
|
|
14
|
+
baseline rather than adding a second style system.
|
|
15
|
+
|
|
16
|
+
## Branches, versions, and channels
|
|
17
|
+
|
|
18
|
+
| Source | Package version | Trigger | npm dist-tag |
|
|
19
|
+
| ----------------------- | --------------- | ----------------------------------------------- | ------------ |
|
|
20
|
+
| `develop` | `X.Y.Z-dev.N` | Successful push CI, with dev publishing enabled | `dev` |
|
|
21
|
+
| Reviewed `main` history | `X.Y.Z-rc.N` | Published GitHub prerelease `vX.Y.Z-rc.N` | `rc` |
|
|
22
|
+
| Reviewed `main` history | `X.Y.Z` | Published GitHub release `vX.Y.Z` | `latest` |
|
|
23
|
+
|
|
24
|
+
Only these version forms are accepted. Update `package.json` and both root
|
|
25
|
+
version entries in `package-lock.json` together, for example using
|
|
26
|
+
`npm version VERSION --no-git-tag-version`. CLI `--version` reads package metadata.
|
|
27
|
+
For explicit releases, add a dated `## [VERSION] - YYYY-MM-DD` changelog section.
|
|
28
|
+
The GitHub tag must match the version, and the prerelease flag must match its channel.
|
|
29
|
+
`latest`, not the tip of `main`, identifies the stable npm release.
|
|
30
|
+
|
|
31
|
+
The checked-in development base starts at `0.1.0-dev.1`. During an eligible push,
|
|
32
|
+
`scripts/dev-release.mjs` replaces `N` with the full history's first-parent commit
|
|
33
|
+
count, updating package/lock versions and `gitHead` only in the runner. It creates
|
|
34
|
+
no version-bump commit, Git tag, or GitHub Release. The same commit yields the same
|
|
35
|
+
version; counters may skip unpublished commits. Change the release base through
|
|
36
|
+
a reviewed PR when starting the next line. Preserve branch history.
|
|
37
|
+
|
|
38
|
+
## CI and publication gates
|
|
39
|
+
|
|
40
|
+
`.github/workflows/publish.yaml` validates PRs and pushes to `main`/`develop`,
|
|
41
|
+
manual CI runs, and published GitHub Releases. Node 22/24 validation must succeed
|
|
42
|
+
before publishing. PRs, main pushes, and manual CI runs cannot publish dev builds.
|
|
43
|
+
Only the publishing job receives `id-token: write`; validation has read-only
|
|
44
|
+
GitHub permissions and no LambdaDB service keys.
|
|
45
|
+
|
|
46
|
+
Publication packs once, tests that exact tarball through a clean installation,
|
|
47
|
+
and publishes the same file with provenance. Do not replace it with a repacked
|
|
48
|
+
artifact after testing. The package includes runtime JavaScript, source maps and
|
|
49
|
+
their source files, and public docs/license; it excludes tests, workflows,
|
|
50
|
+
scripts, `.env`, and `.srcx` state. Production dependencies supply the parser
|
|
51
|
+
WASM assets; package tests exercise parsing with install scripts disabled.
|
|
52
|
+
|
|
53
|
+
Dev jobs are serialized without canceling an active registry write. They check
|
|
54
|
+
the current remote develop head and existing registry artifact/tag state before
|
|
55
|
+
publication, skip stale or superseded work, and reject conflicting artifacts.
|
|
56
|
+
An identical rerun skips writing only when source SHA, tarball integrity, version,
|
|
57
|
+
and `dev` tag agree. `latest` is not changed by ordinary development publication.
|
|
58
|
+
|
|
59
|
+
Registry writes are never automatically retried. Successful dev writes are
|
|
60
|
+
followed by bounded reads for up to five minutes, checking commit, integrity, and
|
|
61
|
+
dist-tag. A `published-verification-pending` failure means publication succeeded
|
|
62
|
+
but verification is incomplete: inspect registry state before retrying the job.
|
|
63
|
+
Do not republish, overwrite versions, or move release tags to work around lag.
|
|
64
|
+
|
|
65
|
+
## First publication and Trusted Publisher setup
|
|
66
|
+
|
|
67
|
+
Complete these steps from a reviewed, validated commit after this setup PR merges:
|
|
68
|
+
|
|
69
|
+
1. Verify npm ownership for the `functional-systems` scope and the package name.
|
|
70
|
+
GitHub organization membership does not establish npm permissions.
|
|
71
|
+
2. Run the validation commands in [CONTRIBUTING.md](CONTRIBUTING.md). Retain
|
|
72
|
+
credentialed live acceptance evidence for the exact release candidate; PR CI
|
|
73
|
+
deliberately does not run service checks.
|
|
74
|
+
3. Prepare the first actual `0.1.0-dev.1` tarball, inspect its inventory, and test
|
|
75
|
+
it with `npm run test:package -- /absolute/path/to/package.tgz`.
|
|
76
|
+
4. With explicit release authorization and npm login/MFA, publish that tested
|
|
77
|
+
artifact using `npm publish /absolute/path/to/package.tgz --access public --tag dev`.
|
|
78
|
+
This one-time local bootstrap does not have GitHub Actions provenance.
|
|
79
|
+
Check all dist-tags afterward: initial publication can also create `latest`.
|
|
80
|
+
Do not represent that prerelease as a stable release or silently rewrite tags.
|
|
81
|
+
5. Configure this package's npm Trusted Publisher with the values below. Enable
|
|
82
|
+
direct `npm publish` permission for the workflow, which does not use staged
|
|
83
|
+
publication. Another LambdaDB package's trust configuration does not cover srcx.
|
|
84
|
+
6. After registry and trust setup are verified, enable the GitHub repository
|
|
85
|
+
variable `NPM_DEV_PUBLISH_ENABLED=true`. This authorizes ongoing publication
|
|
86
|
+
from eligible develop pushes; enabling the variable alone does not trigger one.
|
|
87
|
+
Verify the first subsequent dev workflow, registry metadata, provenance, and
|
|
88
|
+
clean consumer install before reporting automatic publication as operational.
|
|
89
|
+
|
|
90
|
+
| Setting | Value |
|
|
91
|
+
| ------------------------- | -------------------------- |
|
|
92
|
+
| npm package | `@functional-systems/srcx` |
|
|
93
|
+
| GitHub organization | `lambdadb` |
|
|
94
|
+
| Repository | `srcx` |
|
|
95
|
+
| Workflow filename | `publish.yaml` |
|
|
96
|
+
| GitHub environment | None configured |
|
|
97
|
+
| Allowed publish operation | `npm publish` |
|
|
98
|
+
|
|
99
|
+
Use GitHub-hosted runners and npm >=11.5.1. The workflow uses Node 24 for publishing
|
|
100
|
+
and checks npm's version. See the current [npm Trusted Publishing documentation](https://docs.npmjs.com/trusted-publishers/)
|
|
101
|
+
and [npm trust command](https://docs.npmjs.com/cli/v11/commands/npm-trust/) when
|
|
102
|
+
configuring the package; registry requirements can change independently.
|
|
103
|
+
Do not store long-lived npm write tokens or LambdaDB keys in this workflow.
|
|
104
|
+
|
|
105
|
+
## Explicit rc/stable release
|
|
106
|
+
|
|
107
|
+
1. Prepare the version, lockfile, changelog, dependency changes, and migration notes
|
|
108
|
+
on a release branch. Pass local/CI/package checks and live acceptance for the
|
|
109
|
+
candidate. Preserve the tested artifact and evidence.
|
|
110
|
+
2. Promote through a reviewed PR into `main`. Revalidate if release contents change.
|
|
111
|
+
3. After explicit authorization, tag the verified commit as `vVERSION`, push it,
|
|
112
|
+
and publish a GitHub Release. Use prerelease=true for rc and false for stable.
|
|
113
|
+
A draft Release does not publish npm. Development versions use the dev workflow.
|
|
114
|
+
4. The workflow verifies main ancestry and metadata, tests the exact packed
|
|
115
|
+
artifact, and publishes to `rc` or `latest` with provenance.
|
|
116
|
+
5. Verify the registry version/dist-tag, integrity, provenance repository/commit,
|
|
117
|
+
and clean installed binary. Synchronize release-only changes back to develop
|
|
118
|
+
with the next intended development base.
|
|
119
|
+
|
|
120
|
+
Read-only verification:
|
|
121
|
+
|
|
122
|
+
```sh
|
|
123
|
+
npm view @functional-systems/srcx dist-tags --json
|
|
124
|
+
npm view @functional-systems/srcx@VERSION version gitHead dist.integrity dist.attestations --json
|
|
125
|
+
```
|
|
126
|
+
|
|
127
|
+
For a bad release, stop promotion and prepare a new patch. Deprecation and dist-tag
|
|
128
|
+
changes require explicit maintainer action; do not silently downgrade consumers.
|
|
129
|
+
|
|
130
|
+
## Homebrew
|
|
131
|
+
|
|
132
|
+
Add a formula to `lambdadb/homebrew-tap` after the first verified stable npm release.
|
|
133
|
+
Follow the CLI pattern: exact npm tarball and checksum, lockfile from the matching
|
|
134
|
+
immutable source commit, production dependencies installed without scripts,
|
|
135
|
+
and an exposed `srcx` executable. Validate installation on macOS and Linux before
|
|
136
|
+
a separate tap PR. No placeholder formula, tap write, or automatic Homebrew update
|
|
137
|
+
is part of this setup. Dev and rc builds do not update Homebrew.
|