Files

que01 c7425f5ed4 feat: make crosswalk and stop-line offsets solvable

Step 1 of the control-marking task, and deliberately server-only: no handle is
drawn yet. This project already shipped a range handle for `profile.interval`,
which compileGeometry ignores, so the control dragged and changed nothing. The
consumer comes first now.

Two kinds join the taxonomy — `junction-crosswalk-inset` and
`junction-stop-line-offset`, both on the existing `junction-approach` anchor. The
solver writes them onto the approach entry, `applyDirectJunctionPlans` carries
them onto the compiled approach, and `compileControlMarkings` reads them in place
of the module constants it used for every junction. They move markings without
reshaping the junction, so unlike width and cutback they deliberately do not
trigger a boundary recompute.

`applyJunctionConstraint` becomes an explicit switch. Its trailing `else` had
meant every kind that was not approach-width fell through to the cutback
validator, so a new kind would have been silently validated and written as a
cutback. The same non-exhaustive shape in the test fixture's `valueFor` is fixed
the same way, and now throws for an unnamed kind rather than answering with a
corner radius.

design.md's taxonomy is updated with it — a test asserts the two cannot drift,
which is what caught the omission.

Measured on a 41-road workspace with 8 crossings: both constraints change their
marking geometry, neither drags the other, and out-of-range blocks instead of
clamping. That measurement is not in the suite: the synthetic junction resolves
`junction_inset_m` to 0 because its crossing never binds to a plan, and the
committed OSM fixture has no crossings at all. The tests assert the wiring the
handles will depend on — values reaching the approach entry, distinct branches,
blocking diagnostics — and the gap is recorded in the test itself.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

2026-08-28 15:01:36 +08:00

2.3 KiB

Raw Blame History

Workspace Index

Records of all AI Agent work records across all developers

Overview

This directory tracks records for all developers working with AI Agents on this project.

File Structure

workspace/
|-- index.md              # This file - main index
+-- {developer}/          # Per-developer directory
    |-- index.md          # Personal index with session history
    |-- tasks/         # Task files
    |   |-- *.json        # Active tasks
    |   +-- archive/      # Archived tasks by month
    +-- journal-N.md     # Journal files (sequential: 1, 2, 3...)

Active Developers

Developer	Last Active	Sessions	Active File
(none yet)	-	-	-

Getting Started

For New Developers

Run the initialization script:

python3 ./.trellis/scripts/init_developer.py <your-name>

This will:

Create your identity file (gitignored)
Create your progress directory
Create your personal index
Create initial journal file

For Returning Developers

Get your developer name:

python3 ./.trellis/scripts/get_developer.py

Read your personal index:

cat .trellis/workspace/$(python3 ./.trellis/scripts/get_developer.py)/index.md

Guidelines

Journal File Rules

Max 2000 lines per journal file
When limit is reached, create journal-{N+1}.md
Update your personal index.md when creating new files

Session Record Format

Each session should include:

Summary: One-line description
Branch: Which branch the work was done on
Main Changes: What was modified
Git Commits: Commit hashes and messages
Next Steps: What to do next

Session Template

Use this template when recording sessions:

## Session {N}: {Title}

**Date**: YYYY-MM-DD
**Task**: {task-name}
**Branch**: `{branch-name}`

### Summary

{One-line summary}

### Main Changes

- {Change 1}
- {Change 2}

### Git Commits

| Hash | Message |
|------|---------|
| `abc1234` | {commit message} |

### Testing

- [OK] {Test result}

### Status

[OK] **Completed** / # **In Progress** / [P] **Blocked**

### Next Steps

- {Next step 1}
- {Next step 2}

Language: All documentation must be written in English.

2.3 KiB Raw Blame History