vue3js-app/ADDENDA.md

Enumerated Considerations raised by CLAUDE

Forwarded CLAUDE findings, commented or answered by upstream author.

June 19th

1. Blueprint import: Fixed in neusician repo. Revalidate.

2. Hyphenation: Fixed in neusician repo.

3. MIME-type: It is your business. I follow "be strict in your affairs, be most permissive in others'" doctrine, except when there are conflicting security considerations. Worth a thought: Let's stay compatible with text/yaml too, because a score is also supposed to be human readable text, isn't?

4. Not only the table (from earlier CLAUDE findings) was incomplete, but numerous places in sompyler's parsing process remained without the appropriate emissions to AST.log. These have been added (except some which need more bug investigation), some code needed restructuring.

   Revalidate it in respect to compliance to:

   • Deeper levels must come after next higher levels without any "overstumbles"
   • Allowed object paths:
     • SLOT for depth level 00 only
     • PARENT.SLOT with PARENT being a TYPE or the SLOT of next-higher level
     • SLOT.TYPE with SLOT of implied PARENT

5. Correct, they are railsback coordinates. Fixed overstumble.

6. Mentioned slots not in plan should be implemented so they are editable.

7. Envelope co-dependence: Yes, implement checks in v1.

8. If a linked instrument (its path contains slashes, i.e. is stored in a file at server side) is changed, it is dirty like an embedded one and the export triggers an update of NOT_CHANGED_SINCE to the current iso-formatted date. As it is linked and local files are immutable, it must therefore be embedded for the changes to take effect, indeed.

   A modal dialog should be displayed: "Linked instrument {original path} has been changed. Embed it in the score? If not, changes will be discarded. If yes, all voices using the instrument will have their linkage to the instrument fixed by dropping the path part, leaving the basename. If there is already an instrument with that name, you will need to set the name."

   If a linked instrument is not changed, it should be omitted in the exported score. Also drop embedded instruments that are no longer used by a voice, changed or not. Display a warning box that embedded instruments are no longer used, hence dropped, unless retained in a (mute) voice.

9. Do as you recommend.

10. Subchains: Implement it so it is editable, irrespective of its omission in the plan.

11. Implement export hooks for all objects unless you reckon that regarding specific object types the token use would be obscene. Insert placeholders for humans to fill in that case. Get along without YAML library. Follow my advice of implementation:

    1. Every object-handler has an select_export_template() method returning a list of pairs each consisting of:

       1. a list of object slots required to be set. Nested lists of slots are OR-linked. Maybe recursively nested by list of pairs, to be processed recursively. Check for and prohobit sublists mixing both types.

       2. a template to fill and return when all the object slots are defined. The placeholders in the template (not a Javascript Template object) are #n format referring the list index

    2. Check each pair if all listed slots have got a value, and any slot in nested lists. Proceed depth-first for nested template finders.

    3. The first fullfillable template is formatted so that every newline is extended by the required number of indenting space, the first one reduced by two if prefixed by "- ", or rather the rest extended by two.

       Handle templates without newline as inlinable (no block indentation). Composite should be in YAML flow-style if there is no appropriate STRING variant from the Neusik format spec, e.g. for stem-notes with chains.

    4. Do not use inter-object references YAML provides.

    This I would find a proper YAML writer that humans (at least me) would be happy to fiddle with, and may be convertible to other serialization formats besides YAML. But it is an opinion of the upstream author. If the user i.e. the maintainer of the score editor project wants a YAML.js dependency, they may have one, follow them.

12. Yes, proceed.

Some objections not asked for

I question the choice of project structure, given it is an idea of CLAUDE and not deliberately created by the user:

 c0dev0id/sompAIler:
   PLAN/
     sompyler submodule
   neusician/... # forked from neusician
   ...
 
 I would like to suggest:
 
 c0dev0id/sompAIler:
   PLAN/
     sompyler @49a803b    # submodule
     neusician @8c129644  # submodule
     vue3js-app-proposal  # submodule
   __init__.py # defines blueprint = flask.Blueprint(...)
   templates/...
   static/...

In deployment, the local repo root-dir would then be linked again in neusician/score-editor to bring it in line with conditions explained in ./AGENTS.md therein. Looped symlinks could be dangerous, though, for find etc. Separate repositories might be preferable. Reconsider the project structure and have the user confirm the suggested changes.

The name chosen leave to his descretion but should be reconsidered, too. "Sompyler" not being a brand, I had rather he would not provoke confusion "A-I" vs "y" for an add-on to an interface vs the core thing.