Brummel/Aura
1
0
Fork 0
Code Issues 31 Pull Requests Actions Packages Projects Releases Wiki Activity

Hint at the missing Aura.toml when a namespaced type id fails outside a project #185

New Issue
Closed
opened 2026-07-02 22:25:13 +02:00 by Brummel · 0 comments
Brummel commented 2026-07-02 22:25:13 +02:00
Owner
Copy Link
Copy Source

Running aura run (or aura graph build) on a blueprint that references a project-namespaced type id while OUTSIDE any project directory fails with UnknownNodeType — technically true (no project vocabulary is merged, so the id is unknown), but the actual cause is that no Aura.toml was discovered, and nothing says so. A newcomer who scaffolds a project and then runs the host from the wrong directory gets a type-resolution error instead of the orienting "not inside an aura project (no Aura.toml found up from )" diagnosis.

Observed by the milestone fieldtest (finding F5, fieldtests/milestone-project-environment/FINDINGS.md, 2026-07-02); reproduction in the corpus fixtures s4_outside_run.err / s4_outside_build.err.

Likely shape: when type resolution fails on a NAMESPACED id (contains ::) and no project env is loaded, append the hint to the refusal ("type id looks project-namespaced but no Aura.toml was found — run inside a project directory"). The bare-id case stays as is; the hint fires only where the confusion actually arises.

  • depends on: nothing
  • context: post-milestone polish from the green project-environment fieldtest. Sibling of the LoadError-prose issue (filed separately): this one adds the missing-project context, that one fixes the Debug-leak phrasing.
Running `aura run` (or `aura graph build`) on a blueprint that references a project-namespaced type id while OUTSIDE any project directory fails with `UnknownNodeType` — technically true (no project vocabulary is merged, so the id is unknown), but the actual cause is that no `Aura.toml` was discovered, and nothing says so. A newcomer who scaffolds a project and then runs the host from the wrong directory gets a type-resolution error instead of the orienting "not inside an aura project (no Aura.toml found up from <cwd>)" diagnosis. Observed by the milestone fieldtest (finding F5, `fieldtests/milestone-project-environment/FINDINGS.md`, 2026-07-02); reproduction in the corpus fixtures `s4_outside_run.err` / `s4_outside_build.err`. Likely shape: when type resolution fails on a NAMESPACED id (contains `::`) and no project env is loaded, append the hint to the refusal ("type id looks project-namespaced but no Aura.toml was found — run inside a project directory"). The bare-id case stays as is; the hint fires only where the confusion actually arises. - depends on: nothing - context: post-milestone polish from the green project-environment fieldtest. Sibling of the LoadError-prose issue (filed separately): this one adds the missing-project context, that one fixes the Debug-leak phrasing.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
BLOCKER
Core functionality blocked; preempts other selection
 bug
Observable misbehaviour
 feature
Substantial extension; no full spec required
 idea
Droppable; no commitment
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claude (Claude) Brummel
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Brummel/Aura#185
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?