Back to Details

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

日志最低要求内容

  1. Timestamp
  2. Cloud type and cloud target (Dream universe or remote FQDN)
  3. Current profile, project, and application (or global scope)
  4. Scope decision: global/application + short reason
  5. Environment readiness state
    • Dream status (ready/not ready)
    • Docker status (ready/not ready, if Dream path)
  6. Known resources by type (domains, databases, storage, messaging, services, functions, websites, libraries)
  7. Last commands executed and result summary
  8. 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)
  9. CLI versions snapshot 
    • tau version
    • dream --version || dream --help
      (some Dream builds do not expose 
      --version
      )
  1. 时间戳
  2. 云类型与云目标（Dream universe或远程FQDN）
  3. 当前配置文件、项目及应用（或全局作用域）
  4. 作用域决策：全局/应用 + 简短理由
  5. 环境就绪状态
    • Dream状态（就绪/未就绪）
    • Docker状态（若使用Dream路径，则记录就绪/未就绪）
  6. 按类型分类的已知资源（域名、数据库、存储、消息服务、服务、函数、网站、库）
  7. 最近执行的命令及结果摘要
  8. 构建跟踪
    • 最新相关构建/任务ID
    • 最近日志诊断（根因摘要）
    • 构建/任务完成状态（排队中/运行中/成功/失败）
    • 等待/轮询记录（等待时长、最后观测状态）
  9. 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
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