Repository navigation
ADO Lens 0.2.0 - #2
Merged
Merged
Conversation
- ado_trace: acceptance criteria (from the parent for a task) and whether they changed after coding started; changesets, commits and PRs of the item and its tasks with their X++ objects; builds (also deleted ones); every release stage with YES / NOT YET across the projects the code lives in; Git: merged into each mapped branch; tests, tasks, signals - ado_changes: files of a changeset, PR or commit with X++ methods per object; one file's diff (AOT XML per method plus metadata) - environments per connection (config --env staging=UAT) - skill po-verify; skills are part of the package - shorter server instructions; the size check measures the real tool JSON
Checked on a real Git flow (feature branch -> dev, -> staging, -> release branch -> master): - a stage has the work when any of its PRs or commits reached it; later changes not there yet are named (unless a later PR from the same source branch already is) - a PR and its merge commit are one change (the PR keeps the files) - merges of long-lived branches (release -> master) are one line and count as evidence, not as work - repeated file lists become "same N files as PR x" - a requirement uses its parent's text only when it has none of its own - empty bold markers from description templates are dropped
- keys are branches, release definitions or single stages ("Definition/Stage"),
so one stage deploying to two environments at once gets one label
- ado_trace lists the stages in the order of the map (e.g. DEV -> UAT -> PROD)
- map keys that are no branch of the repository are skipped, not reported as
"not merged"
- ado_pr: PRs waiting for my review and mine; one PR with votes, checks, linked work items and the open threads people wrote (system notes and conflict resolution records left out) - ado_pr_update: create, comment on a file and line, reply, resolve, vote, publish, complete, abandon; @[name] mentions - ado_pipeline: recent builds; a failed build with its failed steps, errors and the error lines of the log without MSBuild noise; ado_pipeline_run - ado_settings saves the environment map for good; without a map ado_trace ends with a SETUP note (detected flow and a first guess) so Claude asks once - the tool size check registers Lens as a service like the server does, so it measures what clients really get - CLI: pr, pipeline
Stages without a deployment for half a year are leftovers, not part of the flow, so the proposal leaves them out; the placeholder for an unknown name is <name>.
Checking work against what was asked, and where it is. - `ado_trace` (tool set `trace`): the acceptance criteria (from the parent for a task) and whether they changed after coding started; changesets, commits and pull requests linked to the item and its tasks, with the X++ objects they touch; builds, also those deleted by retention; every release stage of the code's branches with YES / NOT YET, in all projects the code lives in; for Git, whether the change is merged into each mapped branch; tests, tasks, signals. - `ado_changes`: files of a changeset, pull request or commit with added / changed / removed X++ methods per object; the diff of one file — AOT XML per method plus the metadata without raw XML noise; other files as unified diffs. - Environments per connection: `adolens config --connection <c> --env staging=UAT` maps branches, release definitions or single release stages (`"Definition/Stage=UAT + SCM"`) to environment names; any number of steps, listed in that order. - Git flows with a PR per step (feature -> dev, -> staging, -> release branch -> master): a stage has the work when any of its PRs reached it, later changes not there yet are named; a PR and its merge commit are one change; release merges are one line. - Skill `po-verify` (`skills/po-verify`): guides Claude through checking a work item for a Product Owner. - Server instructions keep only advice the tool descriptions do not give (fewer tokens per session); the tool size check measures the JSON Claude really receives and only guards against accidental growth. - Pull requests (tool set `pr`): `ado_pr` (waiting for my review, mine, all active; one PR with votes, checks, work items and the open threads people wrote) and `ado_pr_update` (create, comment on a file and line, reply, resolve, vote, publish, complete, abandon; `@[name]` mentions). - Pipelines (tool set `pipelines`): `ado_pipeline` (recent builds; a failed build with its failed steps, errors and the error lines of the log without MSBuild noise) and `ado_pipeline_run`. - `ado_settings`: shows the connection and saves the environment map; when the map is missing, `ado_trace` ends with a SETUP note (the flow it found and a first guess) so Claude asks the user once and saves the answer. - CLI: `trace`, `changes`, `pr`, `pipeline`.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Checking work against what was asked, and where it is.
ado_trace(tool settrace): the acceptance criteria (from the parent for a task) and whether they changed aftercoding started; changesets, commits and pull requests linked to the item and its tasks, with the X++ objects they
touch; builds, also those deleted by retention; every release stage of the code's branches with YES / NOT YET, in all
projects the code lives in; for Git, whether the change is merged into each mapped branch; tests, tasks, signals.
ado_changes: files of a changeset, pull request or commit with added / changed / removed X++ methods per object;the diff of one file — AOT XML per method plus the metadata without raw XML noise; other files as unified diffs.
adolens config --connection <c> --env staging=UATmaps branches, release definitions orsingle release stages (
"Definition/Stage=UAT + SCM") to environment names; any number of steps, listed in that order.of its PRs reached it, later changes not there yet are named; a PR and its merge commit are one change; release
merges are one line.
po-verify(skills/po-verify): guides Claude through checking a work item for a Product Owner.check measures the JSON Claude really receives and only guards against accidental growth.
pr):ado_pr(waiting for my review, mine, all active; one PR with votes, checks, workitems and the open threads people wrote) and
ado_pr_update(create, comment on a file and line, reply, resolve,vote, publish, complete, abandon;
@[name]mentions).pipelines):ado_pipeline(recent builds; a failed build with its failed steps, errors and theerror lines of the log without MSBuild noise) and
ado_pipeline_run.ado_settings: shows the connection and saves the environment map; when the map is missing,ado_traceends with aSETUP note (the flow it found and a first guess) so Claude asks the user once and saves the answer.
trace,changes,pr,pipeline.