Add a dimension for each artifact type. Use it with collection dimensions to select an artifact.
Command annotations expose projected target types: @check becomes Check, @generate becomes Generator, and @agent becomes AgentMiddleware. dagger up selects plain Service artifacts; it does not require @up. Decide the need for annotation intent for each command. Module function signatures stay unchanged.
For example, these checks belong to the same Go module:
go/modules/test
A dimension identifies an item in a collection. It does not identify every operation on that item.
For example, --go-module=./api can select both a test and a generator. A container such as backend/container may have no dimensions at all.
Making every artifact identifiable through dimensions would require synthetic module, operation, and path dimensions. This would move paths into flags, with more names and rules to learn.
Review baseline: future/module-manifest-v2.md at fa99a6039.
No open item from the previous engine-side review remains.
| Previous issue | Resolution |
|---|---|
| Entrypoint construction | Each driver has an explicit construction rule. |
| Call routing | Constructors use the owning type and an empty function name. Object functions use their original names. |
Related: dagger/dagger#13912 — 1.0: better SDK UX
dagger
├── setup
├── check
├── generate
├── up
golang:test-all on dagger/dagger#13608This briefing answers two related questions:
The short answer is:
To build and release Dagger, we compute and inject a version string. We do this in a way that is slow, breaks separation of concerns, and increases complexity and bugs.
Specifically, the current implementation:
---
name: bullet-style
description: Write tight, parallel-structured bullets for technical problem statements, RFC critique sections, GitHub discussion intros, and design doc analysis. Use when drafting or editing prose where bullets describe how a system behaves and why it's problematic. Triggers on: problem statement, RFC, design doc critique, discussion intro, bulleted analysis, "what's wrong with X."
---
A distilled style guide for technical bulleted critique — problem statements, RFC sections, GitHub discussion intros, anything where a bulleted list describes how a system works and why it's bad.
Markers in the rules below: ✅ explicitly taught through edits;
Build a standalone CLI that mirrors Discord thread state into SQLite.
The tool must not depend on discordex internals. It should be usable by discordex, an admin script, or any other consumer as an external process that owns its own config, Discord connection, database, migrations, and inspection commands.
Yves (eunomie) has an open PR — dagger/dagger#13130 — adding dagger module-checks, a new experimental command that fetches check/trace results from Dagger Cloud and renders them in the CLI. It works, but it's a separate command with its own rendering pipeline, disconnected from the existing dagger check.
Don't add a new command. Make dagger check smarter.