Skip to content

Feat/1015 typed tool handle#41

Merged
Skobeltsyn merged 2 commits intomainfrom
feat/1015-typed-tool-handle
May 5, 2026
Merged

Feat/1015 typed tool handle#41
Skobeltsyn merged 2 commits intomainfrom
feat/1015-typed-tool-handle

Conversation

@Skobeltsyn
Copy link
Copy Markdown
Contributor

No description provided.

Skobeltsyn and others added 2 commits May 4, 2026 20:45
Add a Tool<Args, Result> @JvmInline value class wrapping the underlying
ToolDef. Every tool(...) overload in ToolsBuilder now returns a typed
handle: untyped overloads as Tool<Map<String, Any?>, Any?>, the typed
inline overload as Tool<Args, Result>.

Strictly additive — return value is meaningless on its own and existing
call sites continue to compile and behave identically. The handle is
the foundation for typed Skill.tools(...) / +autoTool(...) overloads
landing in #1016 (KSP P1.2), the first user-visible step of the
KSP initiative described in docs/ksp-design.md.

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

Foundational design note for the KSP / compile-time-validation initiative
spanning issues #1015–#1023. Inventories all 72 runtime require/check/error
sites across the codebase, classifies them into four buckets (DSL
validations / freeze guards / @generable reflection / inherently runtime),
and lays out a three-phase plan: typed tool refs first (Phase 1, no KSP
needed), :agents-kt-ksp module second (Phase 2), kotlin-reflect drop third
(Phase 3).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@Skobeltsyn Skobeltsyn merged commit 93022b7 into main May 5, 2026
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant