o [andybunn] deprecate i.detrend() and i.detrend.series() in favour of the
  app; rarely used. (1.8.0 gave i.detrend() the rwi class and a record of
  each series' method, the minimum while it is still here.)

o [andybunn] kalman.ar() and kalman.spec(): evolutive AR spectra by the
  Kalman filter, asked for by Ed Cook. First version written 2026-10-07 from
  Kitagawa and Gersch (1985), not from Ed's programs. Ed's reply: his
  are two programs (coefficients, then spectrum); he picks the order by
  trying several, not by AIC, and used AR(30) for sunspots. He offered
  to show them at the LTRR in November. Still open:
  - Compare with Ed's programs when we see them: how he sets the state
    noise, how he starts the filter, whether he smooths or only filters.
  - Compare with TSSS::tvar() and tvspc() (not installed here).
  - Maximum likelihood gives lambda = 0 for sunspot.year at order 30;
    the picture Ed describes needs lambda set by hand (about 1e-3).
    Decide what guidance to give on choosing it. profile() on a fit
    (added 2026-10-07) shows the likelihood over lambda.
  - variance = "varying" added 2026-10-07 (innovation variance as a
    random walk in log, from the prediction errors). It is a two-step
    estimate, smooth, and understates sharp changes. It does not
    respond to slow swings such as ca533 near 1400: those are not a
    change in one-step predictability. A wavelet shows them; this
    model does not, whatever the options.
  - A test against surrogates from the fixed-coefficient model, so a
    hand-set lambda can be judged. In trials the hand-set pictures for
    sunspot.year and ca533 were no more variable than surrogates.
  - One internal NA costs order + 1 years. Carrying y in the state
    would avoid that.
  - No significance test and no confidence band on the surface.
  - The plot does not mark where the coefficients are poorly
    determined (the ends); se is in the object.
  - Filter is in R: about 1 s for 2000 years at order 30 ("rw1"),
    3 s for "rw2". Move to C only if that becomes a problem.

o [andybunn] ssf vignette? Better to leave that all in LTLdplR?

o [andybunn] multiple RCS

o [andybunn]  reader for *-rwl-noaa.txt

o [andybunn]  In preparation for reconciling dplR and the developing dplPy this is a good time to revisit many of the "small" choices that exist in dplR. The first discussed by me and KJA is the high freq standardization threshold used in the xdating functions. We should maybe just ape COFECHA directly. 32-yr spline followed by AR with a max lag of five. Any change of this magnitude (and there will be others I expect) should wait for dplR 2.0 timed to the release of dplPy. Sigh. 

o [andybunn]  Victoria H func for EW/LW.

o [andybunn]  json readers and writers?


o [andybunn] read.tucson(): split the negative-value rule. One line,
  tailNums[tailNums < 0 & tailNums != -9999] <- NA, treats a file's
  sentinel (-999, -8, -5, ...) and an apparent sign error (nc030e:
  685 578 651 664 -249 870) the same way, and says nothing about
  either. A value repeated in the file is its sentinel: report it once.
  A lone negative is a suspected sign error: flag it. Both still return
  NA; never flip -249 to 249. Evidence and counts are in the ITRDB clone
  (itrdbMeasurementsClone, project notes, "Reader work still open in
  dplR").

o [andybunn] read.tucson(): decide what to do with a file that has
  exactly one negative cell. The repetition rule above cannot tell a
  sentinel used once from a sign error. 261 ITRDB files, 191 of them a
  single -999. Either report all 261 as undecidable, or treat a file's
  only negative as its sentinel (13 files then get a message).

o [andybunn] read.tucson(): a 999 in the middle of a line in a 0.01 mm
  file is deleted as a stop marker, silently. 21 ITRDB files, 149
  cells. Mostly real markers, but in dza010 (BES04B 1952), bgd002 and
  deu440 it is a plausible 9.99 mm ring. Give it the same treatment as
  sentinels: one message per file with the count.

o [andybunn] read.tucson(): should a line that cannot be read
  unambiguously be an error by default, not only under strict = TRUE?
  Making COLUMN_LAYOUT and PAST_COL72 fatal would newly fail 20 ITRDB
  files. The case for it, file by file, is in
  itrdbMeasurementsClone/notes/read-tucson-fail-on-unreadable.md.

o [andybunn] revamp the plots. Most of dplR's plots were built before
  2010 and need attention.
