minuti.ae

Navidrome 0.64: changing a user’s password over the API

The Subsonic changePassword endpoint returns HTTP 501 in Navidrome 0.64. The native API that the web UI uses works:

1. POST /auth/login with username and password to get a JWT.
2. PUT /api/user/{id} with the full user object plus currentPassword, password, and changePassword: true, sending the header x-nd-authorization: Bearer <token>.

Verified 2026-09-24 against Navidrome 0.64.

SQLite: double quotes are identifiers, not strings

SELECT * FROM runs WHERE outcome="lyrics" returns zero rows when the table also has a column named lyrics, because SQLite reads "lyrics" as that column and compares outcome to it row by row. Double-quoted text only falls back to a string literal when no such identifier exists, and that fallback is a documented legacy misfeature.

Use single quotes or a bound parameter:

SELECT * FROM runs WHERE outcome = 'lyrics';

Verified 2026-09-24.

GitHub Actions: ubuntu-latest does not ship pandoc

A step that calls pandoc on the ubuntu-latest runner (the 24.04 image as of September 2026) fails with pandoc: command not found. It is not in the image’s preinstalled tool list any more. Install it as its own step first:

- run: sudo apt-get install -y -qq pandoc

Verified 2026-09-28.

Entry format 2 begins below

Entries above this line are format 1: a heading, the fact, and a verification line. Entries below carry a Human section with the submitter’s words verbatim and signed, and a Robot section with the analysis signed by the AI that produced it. Older entries are left as they were written.

2022 Toyota Sienna Limited: cargo length with the second row slid fully forward

Human

Submission

2022 Sienna Limited. 75” to back of (irremovable?) second row sliding seats. I think the Limited is a factor on those seats. 95” to cup rest. 4ft wide trunk opening horizontal. Almost 58” diagonal. 100” from back of driver headrest to bottom of trunk door.

Robot asked: where the second-row seats were on their slide track when the 75” was taken, and whether the seatbacks were upright and the third row stowed. It also asked which cup rest the 95” reaches, whether the 100” is straight-line or along the floor, where across the opening the 4 ft was taken, and FWD or AWD.

Follow-up

those measurements were taken with the second row seats pushed as far forwards as they’ll go with the driver/passenger seats far enough forward to permit this.

Signed: Project owner

Robot

All lengths were taken with the second-row seats slid as far forward as they go and the front seats moved forward far enough to allow that. Where a start point is not given below, the submitter did not state it.

• 75 in (6 ft 3 in) to the back of the second-row seats.
• 95 in (7 ft 11 in) to the cup rest. Which cup rest was not stated.
• 100 in (8 ft 4 in) from the back of the driver’s headrest to the bottom of the liftgate opening. Straight line or along the floor was not stated.
• Liftgate opening: 4 ft (48 in) wide, almost 58 in on the diagonal. Where across the opening the width was taken was not stated.

Conflict, recorded as given: 95 in to the cup rest is less than 100 in to the driver’s headrest, yet the front console cup holders sit ahead of the headrest. Either the cup rest is a second-row one or the two numbers have different endpoints.

Second-row seats not removable: partly confirmed. Toyota’s 2022 Sienna Quick Reference Guide (p. 25) gives a removal procedure only for the second-row center seat “(if equipped)”, the middle seat of 8-passenger models; the outboard seats get only slide, tip-up and fold procedures. Toyota does not say outright that the outboard seats cannot be removed.

Trim matters: confirmed. Toyota’s 2021 Sienna launch release says LE and some XLE are 8-seat with a long-slide second row and a stowable middle seat, while some XLE, XSE, Limited and Platinum are 7-seat with Super Long Slide captain’s chairs that slide 25 in (Limited and Platinum FWD add ottomans). The 75 in figure therefore applies to the Super Long Slide seats, not the 8-seat configuration.

Measured by the submitter, 2026-09-29, second row fully forward. Seat-removal and trim claims checked against Toyota’s 2022 Quick Reference Guide and 2021 launch release, 2026-09-29. Cup-rest location, headrest measurement path and liftgate width position not stated; whether the outboard seats can be removed at all unverified.

Signed: Claude Fable 5.1 (Anthropic), running as a Claude Code agent

OpenSpec 1.13.2: a MODIFIED requirement cannot drop or rename a scenario; remove the requirement and add it under a new name

Human

Submission

New post from this chat re: openspec

If you had to fight openspec on this there might be a good reason. Evaluate whether this approach is done within the limits of the best practices of openspec. The only other alternative is that supplanting a requirement just wasn’t planned for, which seems odd to me.

Signed: Project owner

Robot

The submission was a pasted transcript of another AI session, not reproduced here. The second quote above is the submitter’s own turn in it. The transcript’s claims about OpenSpec CLI 1.13.2 (@fission-ai/openspec) are checked below, each against a throwaway project run on 1.13.2 on 2026-10-02, with openspec validate --strict --type change.

What works and what does not, when a requirement in the main spec has to lose one of its scenarios:

• MODIFIED with the scenario left out: refused. MODIFIED "<name>" omits scenario(s) the current spec still has: "<scenario>".
• REMOVED plus ADDED under the same requirement name: refused. Requirement present in both ADDED and REMOVED: "<name>".
• RENAMED plus MODIFIED under the new name with the scenario left out: refused, same message as the first. The transcript did not try this one.
• REMOVED plus ADDED under a different requirement name: valid, and it archives.
• MODIFIED keeping the scenario’s name and reversing its content: valid.

Each claim, with its outcome:

• The refusal is a deliberate data-loss guard: confirmed. Issue #1246 reports two open changes modifying the same requirement, where archiving the second silently overwrote the scenarios the first had added, because MODIFIED replaces the whole requirement block. Issue #1477 reports that archive refused such a delta while validate passed it, and asks validate to run the same check. The 1.13.2 source cites both numbers beside the guard (dist/core/parsers/requirement-blocks.js, dist/core/validation/validator.js).
• The guard compares scenario names only: confirmed. diffScenarioNames in requirement-blocks.js collects the scenario names of the current block and of the modified block and reports every current name the modified block lacks, counting duplicates. Content is not compared, so a rename is refused the same way as a removal. The reproduction in #1477 is itself a rename.
• There is no way to mark a scenario as removed on purpose: confirmed for 1.13.2, where the check in dist/core/specs-apply.js throws whenever a name is missing, with no bypass. Whether upstream has discussed or planned one is unverified. The transcript reports one search of the issue tracker that found nothing, and that search was not repeated here.
• A requirement added this way lands at the end of the spec: confirmed. After archive, the new requirement sat after the requirement that had followed the removed one, so it has to be moved by hand to keep the old position.
• A scenario’s name is its identity, so a name that states the situation survives the outcome changing and a name that states the outcome (“… rejected”) does not: this is the transcript’s reading, not an upstream statement. It is consistent with the two results above (name kept and content reversed is valid, name dropped is refused).

Behaviour reproduced by the robot on OpenSpec CLI 1.13.2, 2026-10-02. Guard origin confirmed via upstream issues #1246 and #1477 and the 1.13.2 source. The original change that hit the guard was not inspected. Upstream guidance on deliberate scenario removal unverified.

Signed: Claude Fable 5.1 (Anthropic), running as a Claude Code agent

Human Addendum

IMO the takeaway is that OpenSpec scenario names need specific naming considerations:

OpenSpec treats a scenario's name as its identity. A name that states the outcome ("… rejected") can't survive the outcome changing; a name that states the situation can.

Signed: Me, again