You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Draft PR #367 adds two things on top of a checked-in map. First, a component ownership sidecar plus archify locate <base>..<head>. The sidecar gives every component id a list of repository path globs, with an excluded list applied first. locate classifies every path in a Git range as touched, uncovered, ambiguous, or excluded, and every component as touched, untouched, or stale. It is pure computation over Git output and two validated JSON files: no model call, no inference, no map edits. Ambiguity is reported, never resolved; --lint makes it an authoring-time failure and leaves uncovered advisory.
Second, drilldown bundles. One directory holds an entry diagram and up to twelve children, bound by diagram id and two digests. Reading is descend-in-place: returning leaves the parent's geometry untouched, and a child whose id or digest does not match is never rendered — the viewer shows a stale card with expected and actual values and the repair command. locate --bundle projects a range onto entry and children, hiding the "files touched inside" chip at zero. No check marks, no success colour, no risk or merge claims.
Two numbers should shape what comes next. E1 classified 50 fix commits and found 16% structurally expressible, so this complements review rather than standing in for it. E3 replayed 100 commits and found 9% needed a sidecar edit, while 68.7% of sources line anchors decayed — identity rests on globs, not line numbers.
1. Map as a review companion in CI. Hypothesis: a receipt attached to a PR answers "where did this land" without opening a viewer. Evidence: #258 and discussion #240 describe it, an external PR action already implements the shape and is blocked at this seam, and #241 and #222 say pipelines want a file, not a browser. review.blocking / advisory is explicit, so consumers never derive a verdict from counts. What would change the decision: ten real PRs where the receipt is dominated by one component or by uncovered — then it says nothing that git diff --stat grouped by directory doesn't. Not building: merge gates, verdicts, images in comments, automatic map edits.
2. Agent-session orientation. Hypothesis: an agent reports which components it touched against the same map. This is the weakest of the four, and nobody in this tracker has asked for it. E1 says 84% of fixes live inside one component, and E3 says 48% of commits touch three or more, so a session summary is rarely one box. Where it earns something is the PR #352 case: 0 touched, 24 uncovered, because 22 paths were a new top-level analyzers/ the map does not claim. "This lands outside the map" is the answer, not a failure. What would change the decision: a session where the projection changed what you read next. Not building: reading transcripts, inferring intent, live overlays.
3. Capability alignment. E1's structural 8 held one repeated shape: 4 commits where a capability existed in one component and was silently missing from siblings, fixed by extracting a shared module. An architecture diagram cannot show that; a capability-by-component view might. That is 4 of 50 — a pattern, not a finding. What would change the decision: several people bringing commits of that shape plus the capability rows they would author. If those rows can only come from inference, we stop. Not building: deriving capabilities from code.
4. Map maintenance ergonomics. Hypothesis: maintenance is not the binding constraint — the first map is. E3's 9% is discrete and cheap, and uncovered returned to zero after each edit. Meanwhile #214 reports ~25 validate/repair rounds for an 8-node diagram, still open in #344. What would change the decision: measured first-map cost on other repositories. If --lint on a fresh repository is mostly ambiguous, the glob language is wrong. Not building: generating maps from code, auto-layout, a coverage gate, promoting sources line anchors.
Three questions:
Run archify locate --lint HEAD on your repository. What fraction is uncovered or ambiguous, and how many components before the answer told you anything?
For direction 1: what would have to be in a PR receipt for you to read the code differently? Name the fields.
Which of the four would you use next month, and on what evidence?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Draft PR #367 adds two things on top of a checked-in map. First, a component ownership sidecar plus
archify locate <base>..<head>. The sidecar gives every component id a list of repository path globs, with anexcludedlist applied first.locateclassifies every path in a Git range astouched,uncovered,ambiguous, orexcluded, and every component astouched,untouched, orstale. It is pure computation over Git output and two validated JSON files: no model call, no inference, no map edits. Ambiguity is reported, never resolved;--lintmakes it an authoring-time failure and leaves uncovered advisory.Second, drilldown bundles. One directory holds an entry diagram and up to twelve children, bound by diagram id and two digests. Reading is descend-in-place: returning leaves the parent's geometry untouched, and a child whose id or digest does not match is never rendered — the viewer shows a stale card with expected and actual values and the repair command.
locate --bundleprojects a range onto entry and children, hiding the "files touched inside" chip at zero. No check marks, no success colour, no risk or merge claims.Two numbers should shape what comes next. E1 classified 50 fix commits and found 16% structurally expressible, so this complements review rather than standing in for it. E3 replayed 100 commits and found 9% needed a sidecar edit, while 68.7% of
sourcesline anchors decayed — identity rests on globs, not line numbers.1. Map as a review companion in CI. Hypothesis: a receipt attached to a PR answers "where did this land" without opening a viewer. Evidence: #258 and discussion #240 describe it, an external PR action already implements the shape and is blocked at this seam, and #241 and #222 say pipelines want a file, not a browser.
review.blocking/advisoryis explicit, so consumers never derive a verdict from counts. What would change the decision: ten real PRs where the receipt is dominated by one component or by uncovered — then it says nothing thatgit diff --statgrouped by directory doesn't. Not building: merge gates, verdicts, images in comments, automatic map edits.2. Agent-session orientation. Hypothesis: an agent reports which components it touched against the same map. This is the weakest of the four, and nobody in this tracker has asked for it. E1 says 84% of fixes live inside one component, and E3 says 48% of commits touch three or more, so a session summary is rarely one box. Where it earns something is the PR #352 case: 0 touched, 24 uncovered, because 22 paths were a new top-level
analyzers/the map does not claim. "This lands outside the map" is the answer, not a failure. What would change the decision: a session where the projection changed what you read next. Not building: reading transcripts, inferring intent, live overlays.3. Capability alignment. E1's structural 8 held one repeated shape: 4 commits where a capability existed in one component and was silently missing from siblings, fixed by extracting a shared module. An architecture diagram cannot show that; a capability-by-component view might. That is 4 of 50 — a pattern, not a finding. What would change the decision: several people bringing commits of that shape plus the capability rows they would author. If those rows can only come from inference, we stop. Not building: deriving capabilities from code.
4. Map maintenance ergonomics. Hypothesis: maintenance is not the binding constraint — the first map is. E3's 9% is discrete and cheap, and uncovered returned to zero after each edit. Meanwhile #214 reports ~25 validate/repair rounds for an 8-node diagram, still open in #344. What would change the decision: measured first-map cost on other repositories. If
--linton a fresh repository is mostlyambiguous, the glob language is wrong. Not building: generating maps from code, auto-layout, a coverage gate, promotingsourcesline anchors.Three questions:
archify locate --lint HEADon your repository. What fraction is uncovered or ambiguous, and how many components before the answer told you anything?All reactions