factory-lines

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Islo Factory lines

Islo Factory流水线

Factory lines are Islo's automation product: multi-stage work with typed routing, loops, schedules, and event triggers. A line (

line.toml

) orchestrates stages; each stage runs a job (

job.toml

); jobs execute in sandboxes with agents doing the judgment work.

Islo Factory流水线是Islo的自动化产品：具备类型化路由、循环、调度和事件触发器的多阶段工作流。一条流水线（

line.toml

）编排多个阶段；每个阶段运行一个任务（

job.toml

）；任务在沙箱中执行，由Agent完成决策工作。

Iron rules

铁则

Never write or edit a manifest from memory. Scaffold with
```
islo job init
```
, read
```
islo schema factory --short
```
and
```
islo schema job --short
```
, validate with
```
--dry-run
```
. Treat every example as a pattern, not a drop-in.
Creating a line follows
```
references/create-a-line.md
```
phase by phase. Phase 2 is an approval gate: present the design summary and wait for explicit approval before creating or deploying anything.
Deploy order matters and is defined once, in create-a-line.md Phase 6: knowledge, then every stage job, then the line last.
Schedules live in the line manifest
```
[trigger]
```
and nowhere else; anything else is reverted on the next deploy.
Harness code ships in sandbox snapshots. Put the stage brief in the job
```
run_agent
```
prompt so a prompt change is a new job version. Leave supporting or fan-out briefs in the snapshot when they would clutter the line/job view. Repo skills may be a fetch-or-clone checkout plus a short pointer. Never copy procedural content into Knowledge.
Agents do the judgment work via
```
run_agent
```
. Do not replace them with hand-written shell business logic or shell-wrapped agent CLIs, and do not put provider tokens in manifests or sandbox env.

切勿凭记忆编写或编辑清单。使用
```
islo job init
```
生成脚手架，查看
```
islo schema factory --short
```
和
```
islo schema job --short
```
，通过
```
--dry-run
```
进行验证。将每个示例视为参考模式，而非直接可用的模板。
创建流水线需严格遵循
```
references/create-a-line.md
```
的步骤逐步进行。第二步为审批节点：在创建或部署任何内容之前，需先提交设计摘要并等待明确审批。
部署顺序至关重要，且在
```
create-a-line.md
```
的第6阶段中一次性定义：先部署知识库，再部署每个阶段的任务，最后部署流水线。
调度配置仅存在于流水线清单的
```
[trigger]
```
部分；任何其他位置的调度配置会在下次部署时被还原。
工具代码需打包在沙箱快照中。将阶段说明放入任务的
```
run_agent
```
提示词中，这样提示词的变更会生成新的任务版本。当辅助或分支说明会使流水线/任务视图混乱时，将其保留在快照中。仓库技能可采用“拉取或克隆检出+简短指针”的形式。切勿将流程性内容复制到知识库中。
Agent通过
```
run_agent
```
完成决策工作。请勿用手写的Shell业务逻辑或封装Agent CLI的Shell脚本替代它们，也不要将提供商令牌放入清单或沙箱环境变量中。

Where to go

参考指引

Task	Read
Build a new line from a request	`references/create-a-line.md`
Write or fix `line.toml`	`islo schema factory --short` , then `references/line-manifest.md` for policy
Write or fix `job.toml`	`islo schema job --short` , then `references/job-manifest.md` for policy
Choose or wire a trigger; schedule rules; webhook vs incoming webhook	`references/triggers.md`
Inspect, steer, or debug a run; a stage failed; no run appeared	`references/run-control-and-debugging.md`
Pick harness or model; use knowledge in stages	`references/harness-models-knowledge.md`
Single-stage job without orchestration (rare, explicit ask only)	`references/standalone-jobs.md`

Starting points: copy the nearest example from islo-labs/islo-agents. There is no in-skill copy; clone or browse that repo if it is not already on disk.

For sandbox lifecycle, snapshots, gateway profiles, incoming webhooks, environments, knowledge CRUD, and the SDK, use the islo platform skill.

任务	参考文档
根据需求构建新流水线	`references/create-a-line.md`
编写或修复 `line.toml`	先查看 `islo schema factory --short` ，再参考 `references/line-manifest.md` 中的规范
编写或修复 `job.toml`	先查看 `islo schema job --short` ，再参考 `references/job-manifest.md` 中的规范
选择或配置触发器；调度规则；Webhook与入站Webhook对比	`references/triggers.md`
检查、控制或调试运行实例；阶段失败；无运行实例出现	`references/run-control-and-debugging.md`
选择工具或模型；在阶段中使用知识库	`references/harness-models-knowledge.md`
无需编排的单阶段任务（罕见，仅在明确要求时使用）	`references/standalone-jobs.md`

起始参考：从islo-labs/islo-agents中复制最接近的示例。本技能内无副本；若本地未克隆该仓库，请先克隆或浏览该仓库。

关于沙箱生命周期、快照、网关配置文件、入站Webhook、环境、知识库增删改查及SDK，请使用Islo平台技能。

Maintenance

维护

scripts/validate_commands.sh

and

scripts/validate_examples.sh

check every documented command and manifest example against the installed CLI; CI runs them.

scripts/validate_commands.sh

和

scripts/validate_examples.sh

会检查所有文档化的命令和清单示例是否与已安装的CLI匹配；CI会运行这些脚本。