Add follow-up support so thoughts and learnings can be explicitly linked and associated rather than living as isolated records.
Why
Structured learnings are useful on their own, but they become much more practical when they can point back to the raw thought process, source notes, or working memory that produced them. Likewise, thoughts should be able to reference the curated learning that came out of them.
This keeps the distinction clear:
thoughts = raw notes, working memory, intermediate observations
learnings = curated, durable lessons
But it also avoids silos between the two.
Recommended scope
Add explicit association support between thoughts and learnings, for example:
a learning may reference one or more source thoughts
a thought may reference zero or more related learnings
links should be queryable in both directions
associations should be lightweight and not require workflow automation
Suggested model options
Possible implementations could include one of:
direct foreign-key style fields for simple one-to-many linking
a join/association table for many-to-many relationships
typed relationships if future expansion to other entities is expected
Acceptance criteria
A learning can be linked to one or more thoughts
A thought can expose related learnings
Links are retrievable in both directions
The model preserves the distinction between raw thoughts and curated learnings
The design does not force heavy workflow or auto-promotion behavior
Non-goals
automatic promotion of thoughts into learnings
semantic memory graph or advanced associative inference
replacing either thoughts or learnings with a single merged model
Rationale
This gives AMCS a clean bridge between working memory and curated knowledge without turning v1 into a giant knowledge-graph project.
## Summary
Add follow-up support so thoughts and learnings can be explicitly linked and associated rather than living as isolated records.
## Why
Structured learnings are useful on their own, but they become much more practical when they can point back to the raw thought process, source notes, or working memory that produced them. Likewise, thoughts should be able to reference the curated learning that came out of them.
This keeps the distinction clear:
- thoughts = raw notes, working memory, intermediate observations
- learnings = curated, durable lessons
But it also avoids silos between the two.
## Recommended scope
Add explicit association support between thoughts and learnings, for example:
- a learning may reference one or more source thoughts
- a thought may reference zero or more related learnings
- links should be queryable in both directions
- associations should be lightweight and not require workflow automation
## Suggested model options
Possible implementations could include one of:
- direct foreign-key style fields for simple one-to-many linking
- a join/association table for many-to-many relationships
- typed relationships if future expansion to other entities is expected
## Acceptance criteria
- [ ] A learning can be linked to one or more thoughts
- [ ] A thought can expose related learnings
- [ ] Links are retrievable in both directions
- [ ] The model preserves the distinction between raw thoughts and curated learnings
- [ ] The design does not force heavy workflow or auto-promotion behavior
## Non-goals
- automatic promotion of thoughts into learnings
- semantic memory graph or advanced associative inference
- replacing either thoughts or learnings with a single merged model
## Rationale
This gives AMCS a clean bridge between working memory and curated knowledge without turning v1 into a giant knowledge-graph project.
Added public.thought_learning_links as a lightweight many-to-many join table between thoughts and learnings.
Added store methods to link/unlink and retrieve associations in both directions.
Added MCP tools:
link_thought_learning
unlink_thought_learning
get_thought_learnings
get_learning_thoughts
Preserved separate raw thought and curated learning models; no auto-promotion/workflow behavior added.
Verification:
go test ./internal/tools ./internal/mcpserver ./internal/store — pass
make build && make test — pass
Blockers:
None. Note: initial make test failed because internal/app embeds ui/dist before it exists; after make build generated UI assets, make test passed.
Leaving the issue open as requested.
Implemented issue #32 on branch `issue-32-link-thoughts-learnings`.
Commit: `81a3470407ad0cdfaa9e06c3224536b369040e21`
PR: https://git.warky.dev/wdevs/amcs/pulls/36
What changed:
- Added `public.thought_learning_links` as a lightweight many-to-many join table between `thoughts` and `learnings`.
- Added store methods to link/unlink and retrieve associations in both directions.
- Added MCP tools:
- `link_thought_learning`
- `unlink_thought_learning`
- `get_thought_learnings`
- `get_learning_thoughts`
- Preserved separate raw thought and curated learning models; no auto-promotion/workflow behavior added.
Verification:
- `go test ./internal/tools ./internal/mcpserver ./internal/store` — pass
- `make build && make test` — pass
Blockers:
- None. Note: initial `make test` failed because `internal/app` embeds `ui/dist` before it exists; after `make build` generated UI assets, `make test` passed.
Leaving the issue open as requested.
Closing after verification: PR #36 (#36) was merged on 2026-07-14T14:42:06Z and implements explicit thought-learning associations. Verification recorded: go test ./internal/tools ./internal/mcpserver ./internal/store; make build && make test.
Closing after verification: PR #36 (https://git.warky.dev/wdevs/amcs/pulls/36) was merged on 2026-07-14T14:42:06Z and implements explicit thought-learning associations. Verification recorded: go test ./internal/tools ./internal/mcpserver ./internal/store; make build && make test.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Summary
Add follow-up support so thoughts and learnings can be explicitly linked and associated rather than living as isolated records.
Why
Structured learnings are useful on their own, but they become much more practical when they can point back to the raw thought process, source notes, or working memory that produced them. Likewise, thoughts should be able to reference the curated learning that came out of them.
This keeps the distinction clear:
But it also avoids silos between the two.
Recommended scope
Add explicit association support between thoughts and learnings, for example:
Suggested model options
Possible implementations could include one of:
Acceptance criteria
Non-goals
Rationale
This gives AMCS a clean bridge between working memory and curated knowledge without turning v1 into a giant knowledge-graph project.
Implemented issue #32 on branch
issue-32-link-thoughts-learnings.Commit:
81a3470407ad0cdfaa9e06c3224536b369040e21PR: #36
What changed:
public.thought_learning_linksas a lightweight many-to-many join table betweenthoughtsandlearnings.link_thought_learningunlink_thought_learningget_thought_learningsget_learning_thoughtsVerification:
go test ./internal/tools ./internal/mcpserver ./internal/store— passmake build && make test— passBlockers:
make testfailed becauseinternal/appembedsui/distbefore it exists; aftermake buildgenerated UI assets,make testpassed.Leaving the issue open as requested.
Closing after verification: PR #36 (#36) was merged on 2026-07-14T14:42:06Z and implements explicit thought-learning associations. Verification recorded: go test ./internal/tools ./internal/mcpserver ./internal/store; make build && make test.