@lloyal-labs/rig 2.0.1 → 3.0.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/LICENSE +107 -0
- package/LICENSE-FAQ.md +256 -0
- package/README.md +78 -72
- package/dist/bundle.d.ts +211 -0
- package/dist/bundle.d.ts.map +1 -0
- package/dist/bundle.js +296 -0
- package/dist/bundle.js.map +1 -0
- package/dist/cancellable-fetch.d.ts +98 -0
- package/dist/cancellable-fetch.d.ts.map +1 -0
- package/dist/cancellable-fetch.js +133 -0
- package/dist/cancellable-fetch.js.map +1 -0
- package/dist/config-store.d.ts +30 -0
- package/dist/config-store.d.ts.map +1 -0
- package/dist/config-store.js +45 -0
- package/dist/config-store.js.map +1 -0
- package/dist/define-app.d.ts +98 -0
- package/dist/define-app.d.ts.map +1 -0
- package/dist/define-app.js +232 -0
- package/dist/define-app.js.map +1 -0
- package/dist/grant-store.d.ts +31 -0
- package/dist/grant-store.d.ts.map +1 -0
- package/dist/grant-store.js +49 -0
- package/dist/grant-store.js.map +1 -0
- package/dist/index.d.ts +13 -6
- package/dist/index.d.ts.map +1 -1
- package/dist/index.js +37 -11
- package/dist/index.js.map +1 -1
- package/dist/node.d.ts +3 -2
- package/dist/node.d.ts.map +1 -1
- package/dist/node.js +3 -2
- package/dist/node.js.map +1 -1
- package/dist/protocol.d.ts +155 -0
- package/dist/protocol.d.ts.map +1 -0
- package/dist/protocol.js +184 -0
- package/dist/protocol.js.map +1 -0
- package/dist/registry.d.ts +87 -0
- package/dist/registry.d.ts.map +1 -0
- package/dist/registry.js +245 -0
- package/dist/registry.js.map +1 -0
- package/dist/reranker.d.ts +25 -7
- package/dist/reranker.d.ts.map +1 -1
- package/dist/reranker.js +103 -63
- package/dist/reranker.js.map +1 -1
- package/dist/resources/types.d.ts +10 -37
- package/dist/resources/types.d.ts.map +1 -1
- package/dist/resources/types.js +12 -0
- package/dist/resources/types.js.map +1 -1
- package/dist/spine-render.d.ts +97 -0
- package/dist/spine-render.d.ts.map +1 -0
- package/dist/spine-render.js +121 -0
- package/dist/spine-render.js.map +1 -0
- package/dist/tools/delegate.js +1 -1
- package/dist/tools/index.d.ts +26 -22
- package/dist/tools/index.d.ts.map +1 -1
- package/dist/tools/index.js +24 -28
- package/dist/tools/index.js.map +1 -1
- package/dist/tools/keyless-search.d.ts +67 -0
- package/dist/tools/keyless-search.d.ts.map +1 -0
- package/dist/tools/keyless-search.js +401 -0
- package/dist/tools/keyless-search.js.map +1 -0
- package/dist/tools/plan.d.ts +31 -4
- package/dist/tools/plan.d.ts.map +1 -1
- package/dist/tools/plan.js +46 -11
- package/dist/tools/plan.js.map +1 -1
- package/dist/tools/report.d.ts +4 -3
- package/dist/tools/report.d.ts.map +1 -1
- package/dist/tools/report.js +4 -3
- package/dist/tools/report.js.map +1 -1
- package/dist/tools/types.d.ts +12 -56
- package/dist/tools/types.d.ts.map +1 -1
- package/dist/tools/types.js +17 -0
- package/dist/tools/types.js.map +1 -1
- package/dist/tools/web-search.d.ts +9 -25
- package/dist/tools/web-search.d.ts.map +1 -1
- package/dist/tools/web-search.js +11 -119
- package/dist/tools/web-search.js.map +1 -1
- package/package.json +9 -6
- package/dist/sources/corpus.d.ts +0 -80
- package/dist/sources/corpus.d.ts.map +0 -1
- package/dist/sources/corpus.js +0 -100
- package/dist/sources/corpus.js.map +0 -1
- package/dist/sources/index.d.ts +0 -12
- package/dist/sources/index.d.ts.map +0 -1
- package/dist/sources/index.js +0 -14
- package/dist/sources/index.js.map +0 -1
- package/dist/sources/web.d.ts +0 -67
- package/dist/sources/web.d.ts.map +0 -1
- package/dist/sources/web.js +0 -104
- package/dist/sources/web.js.map +0 -1
- package/dist/tools/fetch-page.d.ts +0 -48
- package/dist/tools/fetch-page.d.ts.map +0 -1
- package/dist/tools/fetch-page.js +0 -309
- package/dist/tools/fetch-page.js.map +0 -1
- package/dist/tools/grep.d.ts +0 -35
- package/dist/tools/grep.d.ts.map +0 -1
- package/dist/tools/grep.js +0 -84
- package/dist/tools/grep.js.map +0 -1
- package/dist/tools/read-file.d.ts +0 -74
- package/dist/tools/read-file.d.ts.map +0 -1
- package/dist/tools/read-file.js +0 -192
- package/dist/tools/read-file.js.map +0 -1
- package/dist/tools/search.d.ts +0 -34
- package/dist/tools/search.d.ts.map +0 -1
- package/dist/tools/search.js +0 -101
- package/dist/tools/search.js.map +0 -1
package/LICENSE
ADDED
|
@@ -0,0 +1,107 @@
|
|
|
1
|
+
# Functional Source License, Version 1.1, Apache 2.0 Future License
|
|
2
|
+
|
|
3
|
+
## Abbreviation
|
|
4
|
+
|
|
5
|
+
FSL-1.1-Apache-2.0
|
|
6
|
+
|
|
7
|
+
## Notice
|
|
8
|
+
|
|
9
|
+
Copyright 2026 Lloyal Labs
|
|
10
|
+
|
|
11
|
+
## Terms and Conditions
|
|
12
|
+
|
|
13
|
+
### Licensor ("We")
|
|
14
|
+
|
|
15
|
+
The party offering the Software under these Terms and Conditions.
|
|
16
|
+
|
|
17
|
+
### The Software
|
|
18
|
+
|
|
19
|
+
The "Software" is each version of the software that we make available under
|
|
20
|
+
these Terms and Conditions, as indicated by our inclusion of these Terms and
|
|
21
|
+
Conditions with the Software.
|
|
22
|
+
|
|
23
|
+
### License Grant
|
|
24
|
+
|
|
25
|
+
Subject to your compliance with this License Grant and the Patents,
|
|
26
|
+
Redistribution and Trademark clauses below, we hereby grant you the right to
|
|
27
|
+
use, copy, modify, create derivative works, publish, and distribute the
|
|
28
|
+
Software for any Permitted Purpose identified below.
|
|
29
|
+
|
|
30
|
+
### Permitted Purpose
|
|
31
|
+
|
|
32
|
+
A "Permitted Purpose" is any purpose other than a Competing Use. A
|
|
33
|
+
"Competing Use" means making the Software available to others in a
|
|
34
|
+
commercial product or service that:
|
|
35
|
+
|
|
36
|
+
1. substitutes for the Software;
|
|
37
|
+
|
|
38
|
+
2. substitutes for any other product or service we offer using the Software
|
|
39
|
+
that exists as of the date we make the Software available; or
|
|
40
|
+
|
|
41
|
+
3. offers the same or substantially similar functionality as the Software.
|
|
42
|
+
|
|
43
|
+
Permitted Purposes specifically include using the Software:
|
|
44
|
+
|
|
45
|
+
1. for your internal use and access;
|
|
46
|
+
|
|
47
|
+
2. for non-commercial education;
|
|
48
|
+
|
|
49
|
+
3. for non-commercial research; and
|
|
50
|
+
|
|
51
|
+
4. in connection with professional services that you provide to a Licensee
|
|
52
|
+
using the Software in accordance with these Terms and Conditions.
|
|
53
|
+
|
|
54
|
+
### Patents
|
|
55
|
+
|
|
56
|
+
To the extent your use for a Permitted Purpose would necessarily infringe our
|
|
57
|
+
patents, the license grant above includes a license under our patents. If you
|
|
58
|
+
make a claim against any party that the Software infringes or contributes to
|
|
59
|
+
the infringement of any patent, then your patent license to the Software ends
|
|
60
|
+
immediately.
|
|
61
|
+
|
|
62
|
+
### Redistribution
|
|
63
|
+
|
|
64
|
+
The Terms and Conditions apply to all copies, modifications and derivatives
|
|
65
|
+
of the Software.
|
|
66
|
+
|
|
67
|
+
If you redistribute any copies, modifications or derivatives of the Software,
|
|
68
|
+
you must include a copy of or a link to these Terms and Conditions and not
|
|
69
|
+
remove any copyright notices provided in or with the Software.
|
|
70
|
+
|
|
71
|
+
### Disclaimer
|
|
72
|
+
|
|
73
|
+
THE SOFTWARE IS PROVIDED "AS IS" AND WITHOUT WARRANTIES OF ANY KIND,
|
|
74
|
+
INCLUDING WITHOUT LIMITATION WARRANTIES OF FITNESS FOR A PARTICULAR PURPOSE,
|
|
75
|
+
MERCHANTABILITY, TITLE OR NON-INFRINGEMENT.
|
|
76
|
+
|
|
77
|
+
IN NO EVENT WILL WE HAVE ANY LIABILITY TO YOU ARISING OUT OF OR RELATED TO
|
|
78
|
+
THE SOFTWARE, INCLUDING INDIRECT, SPECIAL, INCIDENTAL OR CONSEQUENTIAL
|
|
79
|
+
DAMAGES, EVEN IF WE HAVE BEEN INFORMED OF THEIR POSSIBILITY IN ADVANCE.
|
|
80
|
+
|
|
81
|
+
### Trademarks
|
|
82
|
+
|
|
83
|
+
Except for displaying the License Details and identifying us as the origin of
|
|
84
|
+
the Software, you have no right under these Terms and Conditions to use our
|
|
85
|
+
trademarks, trade names, service marks or product names.
|
|
86
|
+
|
|
87
|
+
## Grant of Future License
|
|
88
|
+
|
|
89
|
+
We hereby irrevocably grant you an additional license to use the Software
|
|
90
|
+
under the Apache License, Version 2.0 that is effective on the second
|
|
91
|
+
anniversary of the date we make the Software available. On or after that
|
|
92
|
+
date, you may use the Software under the Apache License, Version 2.0, in
|
|
93
|
+
which case the following will apply:
|
|
94
|
+
|
|
95
|
+
Licensed under the Apache License, Version 2.0 (the "License"); you may not
|
|
96
|
+
use this file except in compliance with the License.
|
|
97
|
+
|
|
98
|
+
You may obtain a copy of the License at
|
|
99
|
+
|
|
100
|
+
http://www.apache.org/licenses/LICENSE-2.0
|
|
101
|
+
|
|
102
|
+
Unless required by applicable law or agreed to in writing, software
|
|
103
|
+
distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
|
|
104
|
+
WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
105
|
+
|
|
106
|
+
See the License for the specific language governing permissions and
|
|
107
|
+
limitations under the License.
|
package/LICENSE-FAQ.md
ADDED
|
@@ -0,0 +1,256 @@
|
|
|
1
|
+
# Licensing FAQ
|
|
2
|
+
|
|
3
|
+
> Canonical version at https://docs.lloyal.ai/licensing/faq.
|
|
4
|
+
> This file is a synced copy. Edit the canonical source and re-run
|
|
5
|
+
> `scripts/sync-license-faq.sh` in lloyal-sdk to update all copies.
|
|
6
|
+
|
|
7
|
+
|
|
8
|
+
**You can build and sell commercial products using HDK.**
|
|
9
|
+
|
|
10
|
+
> HDK is free to build products with; it is not free to become the
|
|
11
|
+
> replacement HDK platform.
|
|
12
|
+
|
|
13
|
+
That single sentence is the entire restriction reduced to one line. The rest
|
|
14
|
+
of this page is illustration.
|
|
15
|
+
|
|
16
|
+
## The short version
|
|
17
|
+
|
|
18
|
+
HDK 3.0 runtime packages — `liblloyal`, `lloyal-node`, and the lloyal-sdk
|
|
19
|
+
packages (`agents`, `sdk`, `rig`, `apps/corpus`, `apps/web`) — are
|
|
20
|
+
source-available under **FSL-1.1-Apache-2.0** (the Functional Source License,
|
|
21
|
+
Apache 2.0 future grant). FSL is a [Fair Source](https://fair.io) license.
|
|
22
|
+
|
|
23
|
+
Each version converts to Apache 2.0 two years after its release. The
|
|
24
|
+
restriction during those two years is narrow: **you cannot offer a competing
|
|
25
|
+
HDK runtime, a managed HDK service, or an alternative HDK App distribution
|
|
26
|
+
channel.** Everything else — commercial use, redistribution, modification,
|
|
27
|
+
sale, embedding in shipped products — is freely permitted.
|
|
28
|
+
|
|
29
|
+
The reason the channel restriction exists is consumer-protective: every App
|
|
30
|
+
listed on `apps.lloyal.ai` is reviewed by Lloyal Labs for tool-safety,
|
|
31
|
+
manifest conformance, and signature provenance before publication. Pinning
|
|
32
|
+
the App ecosystem to one verified channel keeps the AI-safety review meaningful
|
|
33
|
+
(consumers can rely on a single trust boundary) and prevents protocol
|
|
34
|
+
fragmentation (an App that works on one harness works on every harness).
|
|
35
|
+
|
|
36
|
+
The `harness.dev` CLI and `hdk-create-app` scaffolder are licensed under
|
|
37
|
+
**Apache 2.0** (unrestricted). They're not part of the runtime stack.
|
|
38
|
+
|
|
39
|
+
## Can I ship a commercial product built on HDK?
|
|
40
|
+
|
|
41
|
+
**Yes.** This is the question everyone has and the answer is straightforward.
|
|
42
|
+
Concretely:
|
|
43
|
+
|
|
44
|
+
- **Shipping a paid intelligent inbox app to consumers** — permitted ✅
|
|
45
|
+
- **Selling an Excel-with-AI desktop app to enterprises** — permitted ✅
|
|
46
|
+
- **Embedding HDK in a medical device sold commercially** — permitted ✅
|
|
47
|
+
- **A consulting firm building a custom intelligent harness for a Fortune
|
|
48
|
+
500 client, charging $500K for the engagement, deploying on client
|
|
49
|
+
infrastructure** — permitted ✅
|
|
50
|
+
- **An indie dev shipping a paid productivity app on the Mac App Store** —
|
|
51
|
+
permitted ✅
|
|
52
|
+
- **An OEM shipping HDK inside an infotainment system or industrial device**
|
|
53
|
+
— permitted ✅
|
|
54
|
+
- **A startup building an end-user product on top of HDK** — including
|
|
55
|
+
vertical research apps, workflow tools, and agent applications — permitted
|
|
56
|
+
✅, *as long as the product is not offering HDK itself as a substitute
|
|
57
|
+
runtime, managed HDK service, or competing App distribution channel*.
|
|
58
|
+
- **A research lab using HDK in published academic work** — permitted ✅
|
|
59
|
+
- **Forking HDK on GitHub to learn, modify, demo, or contribute** — permitted ✅
|
|
60
|
+
- **Running HDK internally inside your company for any business use** —
|
|
61
|
+
permitted ✅
|
|
62
|
+
|
|
63
|
+
If you are building something *with* HDK, you are almost certainly fine.
|
|
64
|
+
|
|
65
|
+
## What is actually restricted?
|
|
66
|
+
|
|
67
|
+
The restriction is narrow and specific: **don't become the replacement
|
|
68
|
+
platform vendor**. Concretely:
|
|
69
|
+
|
|
70
|
+
- **AWS / Google / Microsoft launching "Bedrock Managed HDK" or "Vertex HDK"
|
|
71
|
+
as a hosted runtime service** — restricted ❌
|
|
72
|
+
- **A competitor publishing "OpenHDK" as a forked harness runtime under a
|
|
73
|
+
different name** — restricted ❌
|
|
74
|
+
- **A clean-room reimplementation of the HDK runtime in Python / Rust / Go
|
|
75
|
+
intended as a drop-in replacement** — restricted ❌ (Competing Use doesn't
|
|
76
|
+
require forking source code — a reimplementation that competes is the
|
|
77
|
+
same problem)
|
|
78
|
+
- **Launching `apps.competitor.com` as an alternative HDK App distribution
|
|
79
|
+
channel** — restricted ❌
|
|
80
|
+
- **Offering "managed HDK hosting" or "HDK-as-a-Service" as a competing
|
|
81
|
+
SaaS** — restricted ❌
|
|
82
|
+
- **A hosted orchestration service exposing HDK-compatible APIs as a
|
|
83
|
+
substitute for the HDK runtime** — restricted ❌
|
|
84
|
+
|
|
85
|
+
Notice the pattern: every restricted scenario is "become the platform
|
|
86
|
+
vendor," not "build products with HDK." If your project doesn't compete
|
|
87
|
+
directly with the HDK runtime or its distribution channel, FSL doesn't
|
|
88
|
+
affect you.
|
|
89
|
+
|
|
90
|
+
## Why does the LICENSE list four narrow Permitted Purposes then?
|
|
91
|
+
|
|
92
|
+
You may read the FSL LICENSE and see this section:
|
|
93
|
+
|
|
94
|
+
> Permitted Purposes specifically include using the Software:
|
|
95
|
+
> 1. for your internal use and access;
|
|
96
|
+
> 2. for non-commercial education;
|
|
97
|
+
> 3. for non-commercial research; and
|
|
98
|
+
> 4. in connection with professional services that you provide to a
|
|
99
|
+
> Licensee using the Software in accordance with these Terms and
|
|
100
|
+
> Conditions.
|
|
101
|
+
|
|
102
|
+
A careful first reading can mistake this list for the *exclusive* set of
|
|
103
|
+
permitted uses — leading to the (incorrect) conclusion that commercial
|
|
104
|
+
product distribution is prohibited.
|
|
105
|
+
|
|
106
|
+
It isn't. **The operative definition is broader.** Earlier in the same
|
|
107
|
+
section, the license states:
|
|
108
|
+
|
|
109
|
+
> A "Permitted Purpose" is any purpose other than a Competing Use.
|
|
110
|
+
|
|
111
|
+
The four enumerated items are **illustrative examples** added because those
|
|
112
|
+
specific cases are ones a careful reader might otherwise hesitate about
|
|
113
|
+
("is research permitted? is consulting permitted?"). The four items are
|
|
114
|
+
additive clarifications, not a closing of the open-ended definition.
|
|
115
|
+
|
|
116
|
+
Sentry, who authored FSL and uses it on their own software, [confirms this
|
|
117
|
+
explicitly in their FAQ](https://fsl.software):
|
|
118
|
+
|
|
119
|
+
> "You can do anything with FSL software except undermine its producer. You
|
|
120
|
+
> can run it for almost all purposes, study it, modify it, and distribute
|
|
121
|
+
> your changes…"
|
|
122
|
+
|
|
123
|
+
If the license felt restrictive on first read, that's a documented
|
|
124
|
+
[FSL adoption hazard](https://fair.io) — many developers hit the same wall.
|
|
125
|
+
The answer is to read the "any purpose other than a Competing Use" line as
|
|
126
|
+
the operative definition and treat the four enumerated items as examples,
|
|
127
|
+
not as a closed list.
|
|
128
|
+
|
|
129
|
+
## Will it become Apache 2.0?
|
|
130
|
+
|
|
131
|
+
**Yes — automatically, on a per-version schedule.** Each released version of
|
|
132
|
+
the runtime stack converts to Apache 2.0 exactly two years after its release
|
|
133
|
+
date. The conversion is irrevocable and written into the license text — it's
|
|
134
|
+
not a promise from Lloyal Labs, it's a contractual clause.
|
|
135
|
+
|
|
136
|
+
For example: if `lloyal-sdk @lloyal-labs/lloyal-agents` v3.0.0 is released
|
|
137
|
+
on 2026-06-01, that exact version becomes available under Apache 2.0 on
|
|
138
|
+
2028-06-01. Any consumer can elect to use that version under Apache 2.0
|
|
139
|
+
from that date forward — Lloyal Labs takes no action; the grant is
|
|
140
|
+
automatic.
|
|
141
|
+
|
|
142
|
+
New versions released after v3.0.0 start their own two-year clock from
|
|
143
|
+
their own release dates. There is no single global Change Date.
|
|
144
|
+
|
|
145
|
+
## Is this OSI-approved open source?
|
|
146
|
+
|
|
147
|
+
**No, and we want to be honest about that.** FSL is not OSI-approved
|
|
148
|
+
because the OSI definition of open source (clause 6, "No Discrimination
|
|
149
|
+
Against Fields of Endeavor") does not permit restrictions on specific
|
|
150
|
+
use cases. FSL restricts Competing Use. That restriction takes it out of
|
|
151
|
+
strict OSI compliance.
|
|
152
|
+
|
|
153
|
+
FSL falls under the [Fair Source](https://fair.io) classification —
|
|
154
|
+
source-available licenses that are explicitly developer-friendly:
|
|
155
|
+
commercial use permitted, free redistribution, eventual open-source
|
|
156
|
+
conversion. Fair Source is a more developer-friendly framing than the
|
|
157
|
+
generic "source-available" label, which has been tainted by the
|
|
158
|
+
SSPL / Elastic / MongoDB relicensing trauma cycles.
|
|
159
|
+
|
|
160
|
+
What this means practically:
|
|
161
|
+
|
|
162
|
+
- **You can read the source.** ✅
|
|
163
|
+
- **You can modify it.** ✅
|
|
164
|
+
- **You can sell products built with it.** ✅
|
|
165
|
+
- **You can redistribute it (with the same FSL terms).** ✅
|
|
166
|
+
- **It will be Apache 2.0 in two years.** ✅
|
|
167
|
+
- Some enterprise procurement policies that strictly require OSI-approved
|
|
168
|
+
licenses will require an exception for this. We're working on making
|
|
169
|
+
that exception easy to grant.
|
|
170
|
+
|
|
171
|
+
## Why FSL specifically — why not stay Apache?
|
|
172
|
+
|
|
173
|
+
HDK 3.0 introduces installable HDK Apps. Every App declares against a
|
|
174
|
+
specific App protocol — the bytes-locked intro, catalog format,
|
|
175
|
+
tool-selection rule, and boundary marker that the runtime renders into
|
|
176
|
+
the spine. Your App's reliability depends on every HDK runtime your users
|
|
177
|
+
install agreeing on the same protocol.
|
|
178
|
+
|
|
179
|
+
Under a permissive license alone, the protocol is forkable. A
|
|
180
|
+
well-resourced redistributor could fork the runtime, modify the protocol
|
|
181
|
+
surface, and distribute a variant under a different name with captive
|
|
182
|
+
distribution. App developers then face a fragmented ecosystem: target one
|
|
183
|
+
protocol, target both, or pick the bigger distribution and abandon the
|
|
184
|
+
others. The cost of that split is paid by App developers in testing
|
|
185
|
+
burden, divergent behavior, and reliability degradation across runtimes.
|
|
186
|
+
|
|
187
|
+
FSL's two-year Competing Use restriction is shaped to block that
|
|
188
|
+
fragmentation specifically. After the conversion, anyone can build
|
|
189
|
+
whatever they want — by which time the protocol has had enough time to
|
|
190
|
+
stabilize through ecosystem use and the protection is no longer the load-
|
|
191
|
+
bearing thing keeping it coherent.
|
|
192
|
+
|
|
193
|
+
For the longer treatment of this argument, see
|
|
194
|
+
[Why FSL](./why-fsl).
|
|
195
|
+
|
|
196
|
+
We could have used Apache 2.0 and tried to protect only the channel via
|
|
197
|
+
terms-of-service. We could have written a custom license. We chose
|
|
198
|
+
standard FSL because it's:
|
|
199
|
+
|
|
200
|
+
- **Off-the-shelf** — no bespoke license review at every adopter
|
|
201
|
+
- **Recognizable** — Sentry, PowerSync, and others use it
|
|
202
|
+
- **Documented** — the FAQ, definitions, and edge cases have been
|
|
203
|
+
litigated publicly
|
|
204
|
+
- **Time-bounded** — the protocolual Apache 2.0 conversion is the answer
|
|
205
|
+
to the "is this just source-available forever?" critique
|
|
206
|
+
- **Pre-launch** — relicensing at HDK 3.0 launch is structurally
|
|
207
|
+
different from MongoDB / Elastic / HashiCorp relicensing under an
|
|
208
|
+
existing installed base, which is what causes the backlash cycle
|
|
209
|
+
|
|
210
|
+
## What about the lloyal stack — what's under FSL and what's not?
|
|
211
|
+
|
|
212
|
+
| Component | License | Why |
|
|
213
|
+
|---|---|---|
|
|
214
|
+
| `liblloyal` (C++ engine) | FSL-1.1-Apache-2.0 | Native primitives the runtime is built on |
|
|
215
|
+
| `lloyal-node` (N-API binding) | FSL-1.1-Apache-2.0 | The binding that lets Effection drive llama.cpp |
|
|
216
|
+
| `@lloyal-labs/lloyal-agents` | FSL-1.1-Apache-2.0 | Runtime framework |
|
|
217
|
+
| `@lloyal-labs/lloyal-sdk` | FSL-1.1-Apache-2.0 | Runtime framework |
|
|
218
|
+
| `@lloyal-labs/rig` | FSL-1.1-Apache-2.0 | Runtime framework — holds the App protocol |
|
|
219
|
+
| `@lloyal-labs/corpus`, `@lloyal-labs/web` | FSL-1.1-Apache-2.0 | Reference Apps shipped in-tree |
|
|
220
|
+
| **`@lloyal-labs/harness-cli` (the `harness.dev` CLI)** | **Apache 2.0** | Scaffolder — unrestricted for scaffolding new harnesses and Apps |
|
|
221
|
+
| **`hdk-create-app`** (when shipped) | **Apache 2.0** | Scaffolder — same as above |
|
|
222
|
+
| `llama.cpp` (vendored dependency) | MIT (unchanged) | External upstream library; we don't relicense their code |
|
|
223
|
+
|
|
224
|
+
## Can I contribute to HDK?
|
|
225
|
+
|
|
226
|
+
**Yes.** Contributions are welcome under the same FSL license terms. If you
|
|
227
|
+
submit a PR, you're granting Lloyal Labs the right to distribute your
|
|
228
|
+
contribution under FSL-1.1-Apache-2.0 (and automatically under Apache 2.0
|
|
229
|
+
two years after each release that includes it). The CONTRIBUTING file in
|
|
230
|
+
each repo has the details.
|
|
231
|
+
|
|
232
|
+
## I have a use case that's borderline — who do I ask?
|
|
233
|
+
|
|
234
|
+
Email [legal@lloyal.ai](mailto:legal@lloyal.ai) (or open a discussion in the repo). The runtime
|
|
235
|
+
team will help you confirm whether your use case falls under Permitted
|
|
236
|
+
Purpose or Competing Use. We'd rather give you a quick yes than have you
|
|
237
|
+
worry about it.
|
|
238
|
+
|
|
239
|
+
## Further reading
|
|
240
|
+
|
|
241
|
+
- [FSL official site](https://fsl.software) — Sentry's canonical FSL
|
|
242
|
+
resources and FAQ
|
|
243
|
+
- [Fair Source](https://fair.io) — the category FSL belongs to
|
|
244
|
+
- [The FSL template, instantiated for each repo](./fsl-template)
|
|
245
|
+
- [Why we chose FSL over BSL, Apache, or a custom license](./why-fsl)
|
|
246
|
+
|
|
247
|
+
## Is there a safe harbor for building products with the HDK?
|
|
248
|
+
|
|
249
|
+
Yes. The [Lloyal Harness Builder Grant](https://github.com/lloyal-ai/hdk/blob/main/GRANT.md)
|
|
250
|
+
irrevocably guarantees that building, selling, and hosting Harnesses and Apps
|
|
251
|
+
is a Permitted Purpose and never a Competing Use — even products that compete
|
|
252
|
+
head-on with Lloyal's own (including reasoning.run). Only three uses remain
|
|
253
|
+
restricted: offering the HDK itself as a developer framework, hosting the HDK
|
|
254
|
+
as-a-service for third-party developers, and operating a general-purpose App
|
|
255
|
+
distribution channel. Private/internal App distribution and your Harness's
|
|
256
|
+
own plugin system are explicitly permitted.
|
package/README.md
CHANGED
|
@@ -44,38 +44,49 @@ An agent that greps with a narrow pattern and gets 0 matches will broaden the pa
|
|
|
44
44
|
|
|
45
45
|
Depth scales with `maxTurns`. At 2 turns, agents do single-shot retrieval. At 6 turns, agents do 3–4 rounds of iterative refinement. At 20 turns, agents go deep — following citation chains, cross-referencing claims, building evidence maps. The quality difference is in the later tool call inputs.
|
|
46
46
|
|
|
47
|
-
## Sources
|
|
47
|
+
## Sources via the HDK 3.0 App protocol
|
|
48
48
|
|
|
49
|
-
`@lloyal-labs/rig`
|
|
49
|
+
`@lloyal-labs/rig` is the framework layer; concrete `Source` implementations
|
|
50
|
+
ship as separate **apps** under the HDK 3.0 App protocol (RFC §5):
|
|
50
51
|
|
|
51
|
-
|
|
52
|
+
**`@lloyal-labs/corpus-app`** — local files with grep, semantic search,
|
|
53
|
+
read_file, and recursive delegation. Agents investigate a knowledge base by
|
|
54
|
+
pattern matching, reading sections in context, and spawning sub-agents for
|
|
55
|
+
deeper investigation.
|
|
52
56
|
|
|
53
|
-
|
|
57
|
+
**`@lloyal-labs/web-app`** — web search via [Tavily](https://tavily.com) (or
|
|
58
|
+
keyless DuckDuckGo fallback), page fetching with attention-based content
|
|
59
|
+
extraction, and recursive delegation. `BufferingFetchPage` wraps fetch
|
|
60
|
+
results — full content goes to the agent for reasoning, while a parallel
|
|
61
|
+
buffer stores content for post-research reranking. Content extraction uses
|
|
62
|
+
an ephemeral fork to attend over the fetched page and extract summary +
|
|
63
|
+
links via grammar-constrained generation, then prunes the fork — zero net
|
|
64
|
+
KV cost per extraction.
|
|
54
65
|
|
|
55
|
-
|
|
66
|
+
Apps are composable through the registry:
|
|
56
67
|
|
|
57
68
|
```typescript
|
|
58
69
|
import {
|
|
59
|
-
|
|
60
|
-
|
|
61
|
-
TavilyProvider,
|
|
70
|
+
createAppRegistry,
|
|
71
|
+
createInMemoryConfigStore,
|
|
62
72
|
} from "@lloyal-labs/rig";
|
|
63
|
-
import {
|
|
64
|
-
|
|
65
|
-
|
|
66
|
-
|
|
67
|
-
|
|
68
|
-
|
|
69
|
-
|
|
70
|
-
|
|
71
|
-
}
|
|
72
|
-
|
|
73
|
-
if (
|
|
74
|
-
|
|
75
|
-
}
|
|
73
|
+
import { RerankerCtx } from "@lloyal-labs/lloyal-agents";
|
|
74
|
+
import { createWebApp } from "@lloyal-labs/web-app";
|
|
75
|
+
import { createCorpusApp } from "@lloyal-labs/corpus-app";
|
|
76
|
+
|
|
77
|
+
yield* RerankerCtx.set(reranker);
|
|
78
|
+
const configStore = createInMemoryConfigStore();
|
|
79
|
+
if (tavilyKey) yield* configStore.set("web", { tavilyKey });
|
|
80
|
+
if (corpusDir) yield* configStore.set("corpus", { corpusPath: corpusDir });
|
|
81
|
+
const registry = yield* createAppRegistry({ configStore });
|
|
82
|
+
|
|
83
|
+
if (corpusDir) yield* registry.enable(createCorpusApp);
|
|
84
|
+
yield* registry.enable(createWebApp); // keyless fallback if no tavilyKey
|
|
76
85
|
```
|
|
77
86
|
|
|
78
|
-
When multiple
|
|
87
|
+
When multiple apps are enabled, their sources run sequentially — each gets
|
|
88
|
+
the full KV budget. After source N completes, its inner branches are pruned
|
|
89
|
+
and KV is freed for source N+1.
|
|
79
90
|
|
|
80
91
|
### Cross-encoder reranker — four scoring roles
|
|
81
92
|
|
|
@@ -84,7 +95,7 @@ The reranker (a small cross-encoder GGUF — Qwen3-Reranker-0.6B is the recommen
|
|
|
84
95
|
- **`scoreEntailmentBatch`** — texts vs. the original query. Boundary entailment for retrieved content.
|
|
85
96
|
- **`scoreRelevanceBatch`** — dual-score `min(toolQueryScore, originalQueryScore)`. Used in exploit mode when KV pressure tightens focus.
|
|
86
97
|
- **`scoreSimilarityBatch`** — texts vs. an arbitrary reference. Powers echo detection at delegation boundaries (the agent's own task as reference).
|
|
87
|
-
- **`shouldProceed`** — floor gate. Default `_entailmentFloor = 0.
|
|
98
|
+
- **`shouldProceed`** — floor gate. Default `_entailmentFloor = 0` (logit-diff space: `≥ 0` ⇒ model prefers "yes" over "no"; subclasses may tighten or loosen).
|
|
88
99
|
|
|
89
100
|
One model, four roles. The reranker is RIG infrastructure, not a fetch optimization.
|
|
90
101
|
|
|
@@ -126,32 +137,38 @@ Agents that get cut by context pressure (their tool results exceeded KV headroom
|
|
|
126
137
|
|
|
127
138
|
Full architectural walkthrough: [RIG Pipeline reference](https://docs.lloyal.ai/reference/rig/pipeline).
|
|
128
139
|
|
|
129
|
-
##
|
|
140
|
+
## Framework tools
|
|
141
|
+
|
|
142
|
+
| Tool | Description |
|
|
143
|
+
| -------------- | ---------------------------------------------------------------------------- |
|
|
144
|
+
| `ReportTool` | Terminal tool — agents call this to submit findings |
|
|
145
|
+
| `PlanTool` | Grammar-constrained query decomposition with intent classification |
|
|
146
|
+
| `DelegateTool` | Generic recursive-delegation tool — agent calls it to spawn a sub-agent pool |
|
|
130
147
|
|
|
131
|
-
|
|
148
|
+
App-scoped tools (`web_search`, `fetch_page`, `search`, `read_file`,
|
|
149
|
+
`grep`) live in their owning app — `@lloyal-labs/web-app`,
|
|
150
|
+
`@lloyal-labs/corpus-app`, and so on — installed via
|
|
151
|
+
`harness.dev install lloyal/<name>`. Build your own app with
|
|
152
|
+
`harness.dev app <name>`.
|
|
132
153
|
|
|
133
|
-
|
|
134
|
-
| -------------- | ----------------------------------------------------------------------- |
|
|
135
|
-
| `SearchTool` | Semantic search over corpus chunks via reranker scoring |
|
|
136
|
-
| `GrepTool` | Exhaustive regex pattern matching across all files |
|
|
137
|
-
| `ReadFileTool` | Read file content at specified line ranges, tracks per-agent read state |
|
|
138
|
-
| `ReportTool` | Terminal tool — agents call this to submit findings |
|
|
154
|
+
## Search providers
|
|
139
155
|
|
|
140
|
-
|
|
156
|
+
The `lloyal/web` app ships with two interchangeable `SearchProvider`
|
|
157
|
+
implementations exposed from rig so apps can swap providers without
|
|
158
|
+
vendoring an API client:
|
|
141
159
|
|
|
142
|
-
|
|
|
143
|
-
|
|
|
144
|
-
| `
|
|
145
|
-
| `
|
|
160
|
+
| Provider | Description |
|
|
161
|
+
| ---------------------------------- | ----------------------------------------------------------------- |
|
|
162
|
+
| `TavilyProvider` | Tavily-backed web search (key from constructor or env) |
|
|
163
|
+
| `createKeylessSearchProvider()` | Keyless DuckDuckGo fallback with built-in pacer + circuit breaker |
|
|
146
164
|
|
|
147
|
-
|
|
165
|
+
## Node-only surface (`@lloyal-labs/rig/node`)
|
|
148
166
|
|
|
149
|
-
|
|
|
150
|
-
| ---------------------- |
|
|
151
|
-
| `
|
|
152
|
-
| `
|
|
153
|
-
| `
|
|
154
|
-
| `createReranker(path)` | (`/node` subpath) Semantic reranker for chunk scoring and passage selection |
|
|
167
|
+
| Symbol | Description |
|
|
168
|
+
| ---------------------- | -------------------------------------------------------------------------- |
|
|
169
|
+
| `createReranker(path)` | Semantic reranker — runs the cross-encoder GGUF against text batches |
|
|
170
|
+
| `loadResources(dir)` | Walk a directory into `Resource[]` for corpus apps |
|
|
171
|
+
| `chunkResources(rs)` | Split resources into `Chunk[]` for tokenization + reranker scoring |
|
|
155
172
|
|
|
156
173
|
### `DelegateTool`
|
|
157
174
|
|
|
@@ -174,43 +191,32 @@ const delegate = new DelegateTool({
|
|
|
174
191
|
|
|
175
192
|
The agent sees `web_research` (or whatever `name` you give it) as a callable tool. Calling it spawns parallel sub-agents that recurse into the corpus or web. The deeper an investigation goes, the richer the attention state at depth — and the cost of inheritance is zero.
|
|
176
193
|
|
|
177
|
-
##
|
|
194
|
+
## Building your own App
|
|
178
195
|
|
|
179
|
-
|
|
196
|
+
Apps are the HDK 3.0 unit of distribution. An App bundles a
|
|
197
|
+
`Source` + `Tool[]` + `skill.eta` + `app.json` manifest and gets
|
|
198
|
+
shipped to consumers via the signed channel at `apps.lloyal.ai`.
|
|
180
199
|
|
|
181
|
-
|
|
182
|
-
|
|
183
|
-
|
|
184
|
-
|
|
185
|
-
class DatabaseSource extends Source<DatabaseContext, Row> {
|
|
186
|
-
readonly name = "database";
|
|
187
|
-
|
|
188
|
-
get tools(): Tool[] {
|
|
189
|
-
return this._tools;
|
|
190
|
-
}
|
|
191
|
-
|
|
192
|
-
*bind(ctx: DatabaseContext) {
|
|
193
|
-
// Set up tools, reranker, scorer state
|
|
194
|
-
this._tools = [
|
|
195
|
-
new QueryTool(/* ... */),
|
|
196
|
-
new SchemaInspectTool(/* ... */),
|
|
197
|
-
];
|
|
198
|
-
}
|
|
199
|
-
|
|
200
|
-
getChunks(): Row[] {
|
|
201
|
-
return this._results; // buffered for post-research reranking
|
|
202
|
-
}
|
|
203
|
-
}
|
|
200
|
+
Scaffold one with:
|
|
201
|
+
|
|
202
|
+
```bash
|
|
203
|
+
npx harness.dev app my-app
|
|
204
204
|
```
|
|
205
205
|
|
|
206
|
-
The
|
|
206
|
+
The scaffold ships with a working source + two tools calling
|
|
207
|
+
Wikipedia's REST API as a runnable demo backend. Replace the tool
|
|
208
|
+
bodies with your real backend, keep the schemas, and you're a
|
|
209
|
+
`harness.dev publish` away from being installable in any HDK
|
|
210
|
+
harness.
|
|
207
211
|
|
|
208
|
-
See [
|
|
212
|
+
See [docs.lloyal.ai/build-an-app](https://docs.lloyal.ai/build-an-app)
|
|
213
|
+
for the full App protocol contract.
|
|
209
214
|
|
|
210
215
|
## Documentation
|
|
211
216
|
|
|
212
|
-
Full positioning,
|
|
217
|
+
Full positioning, App protocol, reranker mechanics, and pipeline
|
|
218
|
+
patterns at [docs.lloyal.ai](https://docs.lloyal.ai).
|
|
213
219
|
|
|
214
220
|
## License
|
|
215
221
|
|
|
216
|
-
Apache
|
|
222
|
+
See [LICENSE](./LICENSE) (Functional Source License 1.1 — Apache 2.0 Future License).
|