Is this cumbersome strategy to produce a ridiculously strong password valid?
This is a broadly sub-optimal strategy because it violates Kerckhoffs's principle: if the attacker knows as much about the steps you're describing as you do, and only lacks the core secret, then most of these steps become useless for increasing the security of the secret.
Put another way: the steps that you're describing aren't actually increasing the entropy by any significant amount.
It sounds like this use case depends on the &quot;survival&quot; of the secret holder - to be alive and conscious enough to be able to always produce the secret from memory? If so,  the optimal strategy is probably:

maximizing the &quot;memorizable&quot; entropy of the input - a randomly generated passphrase, memorized, in the style of XKCD 936, using a mnemonic narrative constructed around it after the fact to aid recall - but with more entropy (five or six words drawn from a dictionary of 20,000 words or more), in order to be bruteforce-resistant even if stored with a weak/fast hash

maximizing the cracking resistance of the output - a true KDF like high-work-factor bcrypt or well-tuned scrypt (which are well-covered elsewhere). These are better because they are cracking-resistant even when their algorithms are public knowledge.


But really, since you often don't have control over how the input is stored (hashes), it's the first step that really matters - because even a weak hash will protect a strong password.
And if you're constrained to using the KDF that's built into the file storage format, the second step wouldn't apply at all - because you wouldn't have access to the salt because it would be hidden inside the document's hash. So you'd have to store it somewhere, which would be fragile.
So for your use case, it's probably best to let the secret (as a random passphrase) do the work.