lost-rob0t/starintel-gpt-auto-dig

# StarIntel GPT 自动化挖掘 基于证据的研究包，以及使用仓库本地 **`starintel_doc` v0.9.0 分支**作为唯一文档规范的、由 Git 支持的 JSON 数据库。 ## 规范规则 `starintel_doc/` 是唯一的 schema 实现。脚本、技能、验证、迁移、递归目标选择、导入、静态资源浏览器以及生成的 JSON Schema 都直接导入它。不要创建第二个 schema、仅用于提示的“风格”或未记录的字段。 每个文档都使用 v0.9.0 信封（envelope）： ``` _id, dataset, dtype, schema_version, version, date_added, date_updated, title, summary, description, status, language, tags, labels, aliases, keywords, identifiers, sources, evidence, temporal, provenance, assessment, verification, handling, lineage, quality, workflow, geospatial, attachments, related_ids, notes, data, extensions ``` `data` 由 `dtype` 严格筛选。`extensions` 是已声明、带命名空间的逃生舱，用于处理在不丢失数据的情况下尚无法表示的元数据。未声明的顶层字段和未声明的 `data` 字段将无法通过验证。 ## 仓库布局 ``` starintel_doc/ Canonical v0.9.0 schema fork and runtime schemas/ Generated JSON Schema skills/ Auto-dig operating skills scripts/starintel.py Unified CLI scripts/create-db-document.py Transactional canonical DB writer scripts/validate-db.py Strict corpus validator scripts/validate-for-merge.py Mandatory pre-merge gate scripts/migrate-starintel-v0.9.py Full-corpus migration scripts/search-db.py JSON database search scripts/select-targets.py Recursive target selection db//<_id>.ndjson One compact document per file digs///starintel-documents.jsonl manifests/ Corpus and migration manifests ``` ## 必需的文档创建方式 Agent 和自动化工具不得手动编写 `db/` 下的文件。 使用以下命令创建一个规范化记录： ``` python3 scripts/create-db-document.py org \ --dataset example \ --id starintel:org:example \ --title "Example Org" \ --data '{"name":"Example Org","org_type":"company"}' ``` 该脚本会在写入前验证 schema，仅写入 `db//<_id>.ndjson`，并在写入后验证整个仓库，失败时进行回滚。 对于批处理，请在 `db/` 外部创建 JSONL 并将其导入： ``` python3 scripts/starintel.py import records.jsonl ``` 仅在进行有意的修正或更新版本时使用 `--replace`。仅对旧版输入使用 `--migrate`。 `scripts/starintel.py create` 可以生成或检查草稿文档，但绝不能用于直接写入 `db/`。 ## 数据库规范 每个规范化文档必须确切存在于： ``` db//<_id>.ndjson ``` 目录必须等于 `dtype`；字面量 `_id`（包括冒号）必须等于文件名；`_id` 中禁止使用路径分隔符；每个文件必须仅包含一个紧凑的 JSON 对象和一个终止换行符。重复的规范化 ID 是无效的。关系端点 ID 必须解析为规范化记录，除非表示为明确未解析的 schema 端点。 ## CLI ``` python3 scripts/starintel.py types python3 scripts/starintel.py schema --dtype relation python3 scripts/starintel.py schema --output schemas/starintel-doc-v0.9.0.schema.json python3 scripts/starintel.py validate python3 scripts/starintel.py search palantir --dtype org --with-location python3 scripts/starintel.py select-targets \ --query palantir \ --limit 10 \ --emit-documents \ --output recursive-targets.jsonl ``` ## 全面迁移 ``` python3 scripts/migrate-starintel-v0.9.py --write python3 scripts/validate-for-merge.py --site ``` 迁移过程会遍历每个规范化的 DB 记录和挖掘包，将旧的元数据转换为 v0.9.0 信封，在 `extensions.legacy.v0` 下保留无法识别的旧值，将数据包重写为普通的规范 JSONL，移除旧的压缩传输片段，并生成迁移清单。 ## 强制合并关卡 在标记 pull request 为 ready、批准它、启用自动合并或合并它之前，必须运行： ``` python3 scripts/validate-for-merge.py --site ``` 该关卡会检查 Python 编译、所有单元测试、生成的 schema 的可重现性、对每个 DB 和数据包记录的严格验证、规范路径、每文件单记录格式、重复 ID、关系端点、站点生成以及 `git diff --check`。 除非本地关卡和所有必需的 GitHub 检查都针对当前 head commit 通过，否则不得合并文档 PR。失败、挂起、跳过、取消、不可用、陈旧或结果不确定的检查均不算作成功。在修复之前，请将 PR 保持为草稿状态。 绝不要以“以后再修复”为承诺合并无效文档。绝不要为了强行接纳无效数据而削弱 schema、放宽 `additionalProperties` 或滥用 `extensions`。 ## Git 流程 1. 从 `main` 开始。 2. 创建 `agent/`。 3. 提交一个逻辑连贯的 schema、工具或研究事务。 4. 运行 `python3 scripts/validate-for-merge.py --site`。 5. 开启一个向 `main` 提交的草稿 pull request。 6. 仅在当前 head 通过所有检查后才标记为 ready。 7. 仅在验证完全通过（全绿）时才执行 Squash-merge（压缩合并）。 请勿将研究包直接发布到 `main`。

标签：JSON数据库, Python, 人工智能代理, 命令控制, 数据模式验证, 数据采集, 无后门, 网络安全研究, 自动化信息收集, 逆向工具