taubyte-context-log

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Context Log (Mandatory)

上下文日志（必填）

Rule

规则

For every Taubyte workflow, the agent must create/update a log file inside the current project automatically.

对于每个Taubyte工作流，Agent必须自动在当前项目内创建/更新日志文件。

Log file location

日志文件位置

Preferred:

<project_root>/.taubyte_ai/context.log.md

If
```
.taubyte_ai
```
does not exist, create it.
Also maintain append-only:
```
<project_root>/.taubyte_ai/logs.txt
```

首选路径：

<project_root>/.taubyte_ai/context.log.md

若
```
.taubyte_ai
```
目录不存在，则创建该目录。
同时需维护仅追加模式的日志文件：
```
<project_root>/.taubyte_ai/logs.txt
```

Minimum required log content

日志最低要求内容

Timestamp
Cloud type and cloud target (Dream universe or remote FQDN)
Current profile, project, and application (or global scope)
Scope decision: global/application + short reason
Environment readiness state
- Dream status (ready/not ready)
- Docker status (ready/not ready, if Dream path)
Known resources by type (domains, databases, storage, messaging, services, functions, websites, libraries)
Last commands executed and result summary
Build tracking
- latest relevant build/job IDs
- last log diagnosis (root cause summary)
- build/job completion status (queued/running/success/failed)
- wait/poll notes (how long waited, last observed state)
CLI versions snapshot
- ```
tau version
```
- ```
dream --version || dream --help
```
  (some Dream builds do not expose
```
--version
```
  )

时间戳
云类型与云目标（Dream universe或远程FQDN）
当前配置文件、项目及应用（或全局作用域）
作用域决策：全局/应用 + 简短理由
环境就绪状态
- Dream状态（就绪/未就绪）
- Docker状态（若使用Dream路径，则记录就绪/未就绪）
按类型分类的已知资源（域名、数据库、存储、消息服务、服务、函数、网站、库）
最近执行的命令及结果摘要
构建跟踪
- 最新相关构建/任务ID
- 最近日志诊断（根因摘要）
- 构建/任务完成状态（排队中/运行中/成功/失败）
- 等待/轮询记录（等待时长、最后观测状态）
CLI版本快照
- ```
tau version
```
- ```
dream --version || dream --help
```
  （部分Dream构建版本不支持
```
--version
```
  参数）

Build job waiting policy (do not race ahead)

构建任务等待策略（请勿提前执行后续步骤）

Builds are often asynchronous and can take minutes. After any step that triggers a build (push, inject, retry, build command), do not continue to downstream steps that assume a ready build until you have observed completion.

Rules:

If the workflow triggers a build, you must wait/poll until the relevant build(s) are success or failed, or until a reasonable timeout is reached.
Prefer short polling with backoff (e.g. every 5–10s initially, then 15–30s) and record the latest status in
```
context.log.md
```
and
```
logs.txt
```
.
If the build is still queued/running at timeout: stop, tell the user it is still running, and capture the last known build/job IDs and status so the next run can resume.

Recommended commands (examples; use the project’s actual build/log commands):

bash

undefined

构建通常是异步的，可能需要数分钟时间。在触发构建的任何步骤（推送、注入、重试、构建命令）之后，请勿继续执行依赖就绪构建的下游步骤，直到观测到构建完成。

规则：

若工作流触发了构建，必须等待/轮询直到相关构建处于成功或失败状态，或达到合理超时时间。
优先采用带退避的短轮询（例如初始每5–10秒轮询一次，之后改为15–30秒），并在
```
context.log.md
```
和
```
logs.txt
```
中记录最新状态。
若超时后构建仍处于排队中/运行中：停止操作，告知用户构建仍在运行，并捕获最后已知的构建/任务ID和状态，以便下次运行时可以恢复。

推荐命令（示例；请使用项目实际的构建/日志命令）：

bash

undefined

See recent builds and their statuses (capture IDs)

查看最近的构建及其状态（捕获ID）

tau query builds --since 1h

Re-run until completion state changes (poll)

重复运行直到完成状态变更（轮询）

tau query builds --since 1h


When a build fails, capture the build/job ID(s), then pull logs/diagnosis (per the relevant push/build/verify skill) and record:
- root cause summary
- next remediation step
- whether a rebuild/retry was triggered

tau query builds --since 1h


当构建失败时，捕获构建/任务ID，然后拉取日志/诊断信息（根据相关的推送/构建/验证skill）并记录：
- 根因摘要
- 下一步修复步骤
- 是否触发了重新构建/重试

Update triggers

更新触发条件

After login/profile change
After cloud selection
After Dream/Docker readiness checks
After project/application selection
After scope routing decision
After resource creation/edit/delete
After push/build/log checks
After any recovery action
After any CLI install/reinstall attempt

登录/配置文件变更后
云环境选择后
Dream/Docker就绪检查后
项目/应用选择后
作用域路由决策后
资源创建/编辑/删除后
推送/构建/日志检查后
任何恢复操作后
任何CLI安装/重新安装尝试后

logs.txt format (lightweight but complete)

logs.txt格式（轻量但完整）

Append new entries after context updates using this compact structure:

txt

[timestamp] stage=<phase> status=<ok|error>
context: profile=<...> cloud=<...> project=<...> app=<...>
tau_version: <value or error>
dream_version: <value or error>
error: <short message or none>
fix: <short action taken>
progress: <short current state>
footprint: files=<count/list> resources=<count/list>

Rules:

Keep each entry short; include only actionable details.
Always include error + fix when a command fails.
Never skip version capture in logs.

上下文更新后，使用以下紧凑结构追加新条目：

txt

[timestamp] stage=<phase> status=<ok|error>
context: profile=<...> cloud=<...> project=<...> app=<...>
tau_version: <value or error>
dream_version: <value or error>
error: <short message or none>
fix: <short action taken>
progress: <short current state>
footprint: files=<count/list> resources=<count/list>

规则：

每个条目保持简短；仅包含可操作的细节。
当命令失败时，务必记录错误信息及修复措施。
日志中永远不要遗漏版本信息的捕获。

Data collection commands (example)

数据收集命令（示例）

bash

tau --json current
tau --json list domains
tau --json list databases
tau --json list storages
tau --json list messaging
tau --json list services
tau --json list functions
tau --json list websites
tau --json list libraries
tau query builds --since 1h

bash

tau --json current
tau --json list domains
tau --json list databases
tau --json list storages
tau --json list messaging
tau --json list services
tau --json list functions
tau --json list websites
tau --json list libraries
tau query builds --since 1h