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
The generic extractor exposes Go files and manifests, but Ferrus cannot navigate packages, declarations, imports, receiver methods, or module relationships as structured graph facts.
Proposed solution
Add a deterministic Go extractor through the existing Extractor boundary.
Scope:
Support .go source files plus statically readable go.mod and go.work metadata.
Emit packages, functions, methods, receiver types, structs, interfaces, aliases, named types, constants, variables, and bounded declaration metadata with evidence spans.
Emit imports, package membership, embedding, receiver-method, module, workspace, replacement, and declared dependency relationships when statically provable.
Resolve repository-local packages and workspace modules conservatively without invoking go list, the compiler, generators, cgo, or module downloads.
Treat build constraints and platform-specific files explicitly so facts are not presented as universally active when the configuration is unknown.
Preserve dot imports, generated targets, external packages, and ambiguous build-tag results as unresolved or qualified evidence.
What problem does this solve?
The generic extractor exposes Go files and manifests, but Ferrus cannot navigate packages, declarations, imports, receiver methods, or module relationships as structured graph facts.
Proposed solution
Add a deterministic Go extractor through the existing
Extractorboundary.Scope:
.gosource files plus statically readablego.modandgo.workmetadata.go list, the compiler, generators, cgo, or module downloads.Acceptance criteria
Impact on workflow
None. This extends optional derived repository context and must not alter task, run, lease, review, or approval state.