Okay — I need to stop programming, think, and plan ahead; the first is really easy to do, and the latter two should be a back-and-forth process until this are nailed down with more precision. I started the day with the goal of creating flashcards; and while I did indeed make some progress (most of the things were implemented already), some uncertainty arose when trying to handle the automatic fetching of audio — because of conjugation, declensions, etc. which led me to revisit three or four different parts of the process.

I probably need some more top-down programming. I downloaded some literature to read later, but, for now — let's do a quick exercise on that.

# import Lute Terms from .csv and create `LuteEntry` objects
# normalize `LuteEntries`
# match with existing flashcards in Anki
# create new `Flashcard` objects and sync with Anki
# sync with Lute

This is more or less the whole routine of my interaction with Lute. But it has a lot of moving parts, and I spent the last two stints improving small problems in the code and its feedback on all the actions.

Today, for example, when trying to tackle the creation of the Flashcards, I realised I would have to generate the audio: as usual, if the term is a noun, I'd like to have the pronunciation for both the word and its declension (sea is hav, but the sea is havet, and the pronunciation differs a lot — on the Textual interface, I would hardcode the prompt — it would appear in the UI as, for example, hav,hav — for me to manually add the et suffix to the second entry. Oh, what a big digression!) If this is to be automated, every noun must include the gender — and this would happen on the normalising process. Let's expand on that.

# normalize `LuteEntries`
## simple lowercasing of term / tags 
## handle non-existing translation
## handle parent/child
### if child with no parent, create parent
[...]
## normalize `part of speech`
### if term is noun, get gender
### if term is verb, get conjugation pattern
### if term is adjective, ensure existence of parent form
### if term is building, it can go directly into matching
### others (adverb, conjugation, etc.) should be fine

It might not look like much has changed — but this helps a lot. I'm thinking of appending a few checkmarks to the parts that are done (and with another mark for having created the tests). I feel using Claude to think ahead and code probably sped the process a little too much: a lot of new functionality was implemented, maybe testing wasn't so thorough, and it also doesn't help that the steps are now dependent on previous information, or fetching of online resources. Thinking top-down probably helps to nail down the requirements. What a big mess! But it's becoming beautiful, too!