Path filtering is consistent, but current modules keep almost every check selected.
Tested on dagger/dagger at 7e9eaacc37: 845 checks, with collections expanded.
| Change | Selected | Skipped |
|---|---|---|
| No changes | 0 | 845 |
| Root README | 844 | 1 |
Implementation handoff. Design status: agreed direction, with the open decisions below. No implementation has started.
This document replaces the union proposal in the earlier brief. Defer Artifacts.withArtifacts().
Code reviewed: dagger/dagger, commit ce6dc9f9403b52067f5831149eab4871f857185d. Verify the current code before editing. References below point to the reviewed commit.
Status: Design brief. Not implemented. Public API changes require approval.
Each Artifacts value describes a selection and a consistent workspace view. Module code can share execution without engine batch functions.
An artifact identifies a workspace field and the collection keys used to reach it.
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;