Skip to content

A source's decay is set, kept or cleared by updating the source - #19

Merged
gedaiu merged 1 commit into
re-devfrom
feat/source-decay-option
Oct 22, 2026
Merged

gedaiu merged 1 commit into
re-devfrom
feat/source-decay-option

Conversation

@gedaiu

@gedaiu gedaiu commented Oct 22, 2026

Copy link
Copy Markdown

Slice 2 of 5 of RC-003 (a source may decay), on top of #18. A source can now be told to decay over the API; nothing reads the setting yet, so no behaviour changes.

What is in it.

  • PATCH /api/v1/kbs/{kb_id}/sources/{source_id} takes decay: an object turns it on (a missing field takes Lore's value, so {} is Lore's behaviour), null turns it off, leaving the field out changes nothing. The stored object always has all four fields, so a later change of the defaults does not move a source that was set.
  • DecaySettings::validate: max_items and stale_after_days at least 1, half_life_days 1 to 365. A refused value changes nothing.
  • Source and SourceView carry decay; the audit row says decay_changed.
  • docs/design/sources.md describes the option.

Tests. A store test pins keep, set, clear, refuse and the list; a unit test pins that an update body tells a missing decay from a null one; one for the range check.

Not here. The web form: until it exists the option is set over the API. Create does not take decay either; set it after creating.

Checked locally on the rebased branch: cargo fmt --check, cargo clippy --workspace --all-targets -D warnings, cargo test --workspace (1682 passed, 0 failed).

🤖 Generated with Claude Code

@gedaiu
gedaiu merged commit 48a3600 into re-dev Oct 22, 2026
6 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