chore(lint): dot access for the project span-attribute key

[drewstone]

#432's loop-prefix removal left attrs['project'] where biome's useLiteralKeys wants attrs.project. One-line lint fix, zero behavior change — restores a green pnpm run lint on main.

[tangletools]

✅ Auto-approved drewstone PR — d36c13ac

This PR was opened by the trusted drewstone account.
The full PR reviewer audit still runs separately and will publish findings if it detects issues.

_{tangletools · auto-approval · reason: drewstone_author · 2026-07-02T05:51:04Z}

[tangletools]

🟢 Value Audit — sound

Verdict	sound
Concerns	0 (none)
Heuristic	0.0s
Duplication	0.0s
Interrogation	49.5s (2 bridge agents)
Total	49.5s

💰 Value — sound

One-line lint fix converting a valid-identifier bracket access to dot access to satisfy biome's useLiteralKeys; zero behavior change, restores green lint on main.

• What it does: In src/intelligence/intelligence.test.ts:164, changes the test assertion expect(attrs['project']).toBe('support-agent') to expect(attrs.project).toBe('support-agent'). Functionally identical access (project is a valid JS identifier), but satisfies biome's useLiteralKeys rule. The sibling attrs['tangle.outcome.success'] on line 165 is correctly left as bracket access because the key contains
• Goals it achieves: Restore a green pnpm run lint on main. The assertion was introduced in #432 (commit 7c4dec8) when the new flatOtelSpan builder landed; biome flags the bracket form as unnecessary for valid-identifier keys. The fix unblocks lint without altering test semantics.
• Assessment: Correct and minimal. The conversion from attrs['project'] to attrs.project is exactly what useLiteralKeys demands, and it's applied only where the key is a valid identifier — the dotted key on the following line is untouched, which is the right judgment. One file, one line, no behavior delta. This is in the grain of the codebase (restores a passing lint gate that #432 inadvertently broke).
• Better / existing approach: none — this is the right approach. I confirmed via git log that #432 introduced the offending line and via repo-wide grep that no useLiteralKeys config or helper exists that would make this unnecessary; the only fix the rule accepts is dot-access for valid-identifier keys.
• Model: opencode/zai-coding-plan/glm-5.2
• Bridge attempts: 2
• Bridge warning: opencode/kimi-for-coding/k2p7: bridge stream ended without value-audit content

🎯 Usefulness — sound

Trivially correct one-line lint fix: dot notation for a literal key, zero behavior change, restores a green lint on main.

• Integration: Already reachable — it's a test assertion inside intelligence.test.ts:164 exercised by createIntelligenceClient / traceRun — Observe. No unreachable surface.
• Fit with existing patterns: Matches biome's useLiteralKeys rule, which is part of the recommended ruleset enabled at biome.json:25. The adjacent line 165 correctly retains bracket notation for the non-literal key tangle.outcome.success — so the change shows good judgment about where the rule applies. No competing pattern.
• Real-world viability: Identical runtime semantics — attrs.project and attrs['project'] are indistinguishable in JS. No concurrency, error-path, or edge-input implications.
• Model: opencode/deepseek/deepseek-v4-pro
• Bridge attempts: 3
• Bridge warning: opencode/zai-coding-plan/glm-5.2: bridge stream ended without value-audit content; opencode/kimi-for-coding/k2p7: bridge stream ended without value-audit content

No concerns — sound change, no better or existing approach found. ✅

---

What this audit checks

It judges the change on its merits — not whether it was tasked out in an issue. Unticketed, fast-moving work is fine; the question is whether the change is good and whether a better or existing approach should be used instead.

Pass	What it asks
Heuristic	Vague title? Whitespace-only or cruft-bearing diff? (content signals only)
Duplication	Do added function/class names already exist elsewhere in the repo?
Value Audit	What does it do? What goal does it achieve? Is it good? Better architecture or already-exists?
Usefulness Audit	Does it integrate and fit? Will it hold up in real use and actually get used?

Findings are concerns, not blocks — the human reviewer decides what to do with them.

_{value-audit · 20260702T061413Z}

[tangletools]

✅ No Blockers — d36c13ac

Review health 100/100 · Reviewer score 95/100 · Confidence 65/100 · 0 findings (none)

	opencode-kimi	glm	deepseek	aggregate
Readiness	95	95	95	95
Confidence	65	65	65	65
Correctness	95	95	95	95
Security	95	95	95	95
Testing	95	95	95	95
Architecture	95	95	95	95

Reviewer score is advisory once the run is complete and the verdict has no blockers.

Full multi-shot audit completed 1/1 planned shots over 1 changed files. Global verifier still owns final merge decision. | Full multi-shot audit completed 1/1 planned shots over 1 changed files. Global verifier still owns final merge decision. | Full multi-shot audit completed 1/1 planned shots over 1 changed files. Global verifier still owns final merge decision.

No findings.

---

_{tangletools · 2026-07-02T06:14:26Z · trace}

[tangletools]

✅ Clean — d36c13ac

Full multi-shot audit completed 1/1 planned shots over 1 changed files. Global verifier still owns final merge decision. | Full multi-shot audit completed 1/1 planned shots over 1 changed files. Global verifier still owns final merge decision. | Full multi-shot audit completed 1/1 planned shots over 1 changed files. Global verifier still owns final merge decision.

Full immutable report for this review: trace

Summary comment for this run: full summary

---

_{tangletools · 2026-07-02T06:14:26Z · immutable trace}