@burnt-labs/provider-registry-types
供供应商登记处使用的文物类型、Zod图和JSON Schema
https://api.provider-registry.burnt.com。 。 。 .
npm install @burnt-labs/provider-registry-types zod
import {
RegistryArtifactSchema,
SUPPORTED_ARTIFACT_SCHEMA_VERSION,
type RawProvider,
type ProofPlan,
type ProviderHostGroup,
type EndpointHostBinding,
} from '@burnt-labs/provider-registry-types';
const artifact = RegistryArtifactSchema.parse(await res.json());
生成的 JSON Schema 在
@burnt-labs/provider-registry-types/schema.json 不使用的消费者
zod(Rust核查员,CI符合工作).
zod 兼容性
zod 是一个 端点 依赖,所支持的范围是
^3.25.0 || ^4.0.0。 。 。 .
佐德3.25号舰 整个佐德4号 zod/v4 子路径,这就是这个
包的进口——因此,一个被钉入zo3.25的消费者得到同样的类型,而且
与Zod 4上的相同,不迁徙。 这很重要,因为
最大的消费者,EENOS的 data-ops向~20名工人出口zod计划
,并且不能单独移动此软件包的版本.
A. 向《公约》缔约国作出声明 楼层 范围,而不是
最新 zod, 这是负载而不是偶然的: zod 4.4.3 给
ZodDiscriminatedUnion zod 3. 25 捆绑 v4 的第二个类型参数
因此,针对4.4.3的申报在3.25上失败 TS2707编辑
更古老,更狭义的 两者都能满足. npm run check:consumer-compat 输入
源 repo 将这个焦油球打包, 并编译一个针对每个版本的消费者
范围,所以限制是检查而不是记住.
其根验证 a 登记文物 - 字节在
/.well-known/provider-registry/providers.json 因此,汇编文件
交给它就是全部工作 其他形状是 $ref 目标
而不是替代根源:
{ "$ref": "https://burnt.com/schemas/provider-registry.schema.json#/$defs/ClaimOutputArtifact" }
根有意识地断言一些东西. 仅包含的图案文件
$defs 没有根的断言, 一个空的计画接受每一个实例——
{} 财务报告和审定财务报表 null 包括——虽然看起来完全像一个验证步骤
通过了。 发电机拒绝放出一个.
为什么会这样
消费者生活在单独的储存库中,没有共用建筑——EWOS 萨特亚验证员 世博会SDK 在这个包之前 他们唯一的选择是 手写型号或从另一回购中销售的图案副本,以及两者 腐烂无声. 对供应商的固定装置探测器进行验证 无:比较的两边被冻结.
存在两个部分说明,两者均无权威性和无权威性 准确性 :
- 该服务自己的 OpenAPI 输入了信封, 但声明
endpoints: unknown[]并省略proofPlans完全; tls-app-attest/contracts/provider_template.schema.json输入了身体,但是 设定additionalProperties: false而服务服务服务三把钥匙 他们没有申报,所以它拒绝了51个活供者的16个.
此软件包来自服务验证的 zod, 所以类型 被送达的字节不能有异议.
合同规则
- 物体是添加剂安全. 未知的密钥通过, 所以一个新的上游 字段从不打破消费者。 经核实的现场直播:登记从51起到52起 在开发过程中提供商和计划没有改变地接受新的计划.
- 消费者所读的每个字段都被宣布. 包罗万象是给田地的 不要解释, 永远不要躲藏的地方 我们做的人.
- SDK被解释的巢地很严格.
auth保持添加剂安全, 时auth.submitSignal[]条目及其请求/答复规则拒绝未知 键,执行 Expo SDK 词汇,需要独特的ID和犬形 HTTPS URL, 在 2048 个字符时盖住每个修剪匹配字符串,验证 JSON- path 语法,并盖住 提供商在32个登录封面的regexs中,在出版前总计8192个字符. - 无法关闭倒塌的地板. 拒绝一个
registryVersion以下为minimumAllowedRegistryVersion; 地板移动 当一个提供者被禁用时, 因此一个更古老的缓存文物可以呈现一个被吊销的 提供者为活动 . - 出版物没有准备好.
metadata.isSatyaReady是一个装饰的装饰工具 标记,不是判决,和templateGovernance.providerActivationState是一个 又分出一轴。 残疾提供者 文物中的遗物 - 过滤器 在球场上,永远不要缺席.
合同增加额
下个——动态主机绑定
声明 tlsIdentityPolicy.hostGroups,终点 hostBinding,以及
replayCapturedUrl。一个固定的装订参考文献,一个被命名的精确主机组
Devtool 语义验证器( 不是 JSON Schema 单独执行) 执行每个主机的指针、路径和正则
限制、组限制和验证计划主机交叉点。 消费者必须继续失败
在未知的主机绑定模式上关闭 .
0.0 -- -- 类型 auth.submitSignal
引入了打入的单通登录-提交信号合同. 后被 在生产登记册上启用该功能之前的0.4.0阵列合同.
中断更改
0.4.0 — 多个登录提交信号
RawProvider.auth 而其仅演示文稿的登录提交信号现已输入
zod和JSON Schema的合同. submitSignal a. 命令数组为1至16个条目;
每个都需要一个独特的稳定ID和条形HTTPS URL,并支持 URL 绑定请求
规则、请求 bodyContains编号 :bodyRegex,回应 bodyContains编号 :bodyRegex,可选
导航 regex,一个1000–15000ms超时,以及响应状态处理. 未知的直接
auth 兄弟姐妹们仍然通过以进行前向相容性; SDK 解译条目
严格。 Regexes 必须编译、不包含回溯引用和通过定界静态
回溯跟踪分析; 锚地正则exs and use bodyContains 用于子字符串检查.
添加、编辑或重新排序 auth 变动 policyHash 因为政策预测
复制它逐字.
这取代了0.3.0单吨 submitSignal 对象的数组,其条目
需求 id 财务报告和审定财务报表 url。 。 。 .
0.2.0 - (中文(简体) ) session_stored → sessionStored
登记簿为这只蛇提供了服务,而其他的钥匙是骆驼Case,以及
时 provider-policy校正规则宣布骆驼Case拼写
规则没有匹配 并且字段在写作时无效
它的存在。 电线格式被重新命名为拼写规则,这个计划
和核查员的 政策记录投影 已经使用.
消费者阅读 provider.session_stored 必须读取 provider.sessionStored。 。 。 .
它没有双重服务: 旧的拼写在书写上被拒绝,所以是一件文物
在迁移后只发布新版本.
球场的一部分 policyHash,因此,受影响的供应商的散列车改变了
重命名 。 核对新取来的物品 而不是缓存的.
不编辑 src/schema.ts
它是产生的。 编辑
backend/src/schemas/provider-registry.schema.ts 在此重播和运行中:
npm run generate:types-package
CI在一棵肮脏的树上再生和失败 计划的工作验证了 现场直播 艺术品与这个计划相抗衡.
生成的 dist/schema.json 是一个结构交换计划。 出版必须使用
RawProviderSchema 和 Devtool 政策验证器作为权威语义门用于
jSON Schema 无法保存或充分表达,包括犬科登录提交
URL,URL规则绑定,独特的信号ID,安全的正则表达式,以及完善的Unicode.