Lineage Go Runtime Guardrails
This is a Lineage-specific overlay for high-quality Go work. Use broad Go/backend expertise for implementation details; use this skill to keep the code aligned with what Lineage is trying to be.
Product Boundary
Lineage is a local distribution layer for agent environments. It packages and activates local agent context; it is not a workflow engine, marketplace, cloud service, billing system, vector database, or replacement for Claude/Codex/Cursor/etc.
Runtime Rules
- Keep core runtime code provider-neutral. Provider-specific behavior belongs behind explicit adapter/registry/shim boundaries.
- Treat packages, manifests, archives, and setup declarations as untrusted input.
- Prefer immutable, deterministic state: stable ordering, normalized paths, content hashes, and reproducible manifests.
- Make operations idempotent. Running the same command twice should not duplicate entries, corrupt files, or drift silently.
- Preserve resumability: partial local work should either be recoverable or fail before unsafe writes happen.
- Avoid package behavior that depends on wall-clock time, machine-specific absolute paths, or hidden global state unless the value is clearly local metadata.
- Keep errors actionable and safe to print. Never include secret values in error output.
Go Quality Bar
- Use simple packages and clear ownership boundaries before adding abstractions.
- Prefer standard library APIs for filesystem, hashing, archives, and path handling unless a dependency clearly improves safety.
- Keep command logic thin; put testable behavior in
internal/.
- Sort discovered names before returning or printing them.
- Use table tests for format, validation, path-safety, and idempotency behavior.
- Add regression tests for every bug fix that touches package discovery, config resolution, materialization, launch planning, or safety checks.
Required Verification
Run:
go test ./...
For CLI-facing behavior, verify output and failure modes in tests. For package/materialization behavior, test repeated runs and unsafe input.
1---2name: lineage-go-runtime-guardrails3description: Use when writing or reviewing Lineage Go runtime code, package loading, manifests, object storage, materialization, provider registries, shims, or tests. Apply normal Go/backend engineering skill first, then enforce these Lineage-specific constraints.4---56# Lineage Go Runtime Guardrails78This is a Lineage-specific overlay for high-quality Go work. Use broad Go/backend expertise for implementation details; use this skill to keep the code aligned with what Lineage is trying to be.910## Product Boundary1112Lineage is a local distribution layer for agent environments. It packages and activates local agent context; it is not a workflow engine, marketplace, cloud service, billing system, vector database, or replacement for Claude/Codex/Cursor/etc.1314## Runtime Rules1516- Keep core runtime code provider-neutral. Provider-specific behavior belongs behind explicit adapter/registry/shim boundaries.17- Treat packages, manifests, archives, and setup declarations as untrusted input.18- Prefer immutable, deterministic state: stable ordering, normalized paths, content hashes, and reproducible manifests.19- Make operations idempotent. Running the same command twice should not duplicate entries, corrupt files, or drift silently.20- Preserve resumability: partial local work should either be recoverable or fail before unsafe writes happen.21- Avoid package behavior that depends on wall-clock time, machine-specific absolute paths, or hidden global state unless the value is clearly local metadata.22- Keep errors actionable and safe to print. Never include secret values in error output.2324## Go Quality Bar2526- Use simple packages and clear ownership boundaries before adding abstractions.27- Prefer standard library APIs for filesystem, hashing, archives, and path handling unless a dependency clearly improves safety.28- Keep command logic thin; put testable behavior in `internal/`.29- Sort discovered names before returning or printing them.30- Use table tests for format, validation, path-safety, and idempotency behavior.31- Add regression tests for every bug fix that touches package discovery, config resolution, materialization, launch planning, or safety checks.3233## Required Verification3435Run:3637```bash38go test ./...39```4041For CLI-facing behavior, verify output and failure modes in tests. For package/materialization behavior, test repeated runs and unsafe input.
agentic-lineage