7bc1ad4536
Also updated fixtures/ast.log. Understand the addenda file in connection with vue3js-app-proposal-for-sdk-claude/README.md and CLAUDE's findings in response.
128 lines
5.5 KiB
Markdown
128 lines
5.5 KiB
Markdown
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.
|