feat!: cut over to the four-tool v2 interface - #39
Conversation
5c28eb0 to
664357f
Compare
4e28f2f to
9ae1d2d
Compare
664357f to
aff7e51
Compare
9ae1d2d to
7cb67e7
Compare
|
@codex review |
jack-arturo
added
babysit:waiting-codex
aff7e51 to
a32f0e2
Compare
7cb67e7 to
3c2db90
Compare
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3c2db9096d
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
a32f0e2 to
35c082a
Compare
3c2db90 to
7007538
Compare
35c082a to
e63b835
Compare
7007538 to
9f5ffc9
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 9f5ffc912f
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
e63b835 to
446692e
Compare
9f5ffc9 to
c8669c7
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c8669c71f7
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
* chore(runtime): stage Node 22 and MCP v2 dependencies * feat(client): add isolated Pirsch API v1 read foundation * feat!: cut over to the four-tool v2 interface * chore(runtime): stage Node 22 and MCP v2 dependencies * feat!: cut over to the four-tool v2 interface * chore: align Pirsch with 2026 toolchain
446692e to
2ce09fe
Compare
6679263 to
e8cc8a9
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: e8cc8a9065
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if (input.period) { | ||
| const range = getDateRange(input.period); | ||
| const current = { from: isoDate(range.start), to: isoDate(range.end) }; | ||
| return { current, previous: previousRange(current.from, current.to) }; |
There was a problem hiding this comment.
When pirsch_compare_periods is called with a named period and either an input timezone or configured PIRSCH_TIMEZONE, this computes today, yesterday, week, and month boundaries from the host's UTC calendar instead. Near midnight, a domain such as America/Los_Angeles can therefore query the next local date (and compare the wrong periods) even though that timezone is forwarded to Pirsch. Derive the named range using the effective request/domain timezone before issuing the four queries.
Useful? React with 👍 / 👎.
| if (input.from && input.to && input.from === input.to && input.fromTime && input.toTime && input.fromTime > input.toTime) { | ||
| ctx.addIssue({ code: 'custom', path: ['toTime'], message: 'toTime must be on or after fromTime for a same-day range.' }); | ||
| } |
There was a problem hiding this comment.
For a same-day named period such as { period: "today", fromTime: "18:00", toTime: "09:00" }, this check is skipped because the caller did not supply from and to; resolveComparisonRanges later injects the same date for both bounds and sends the reversed time range upstream. Apply the same same-day clock validation after resolving today/yesterday, or make the refinement account for those named periods.
Useful? React with 👍 / 👎.
jack-arturo
added
babysit:active
|
Babysit stopped — |
jack-arturo
added
babysit:blocked
|
Superseded by the merged v2 stack: #52 (legacy dispatcher retirement), #54 (legacy client retirement), and #53 (v2 stdio cutover). The final main-branch audit verified the four-tool v2 surface, documentation, lifecycle handling, client retirement, and release workflow. Closing this conflicted monolith without merging it. |
jack-arturo
removed
the
babysit:blocked
1 participant
Summary
Validation
tools/list(exactly four tools)Part 5 of the Pirsch MCP v2 stack; depends on #38. Large by necessity: 3,561 of 3,824 changed lines are legacy removals and their generated lockfile cleanup.