[WIP] standardize per card /web deployments and add new info.yaml fields

[philmillman]

Deployments

• adds deployment of per card /web (default) or custom folder (overridable via Editor)
• assumes prebuilt files, we can run a build per card in the future, but that might eat up a lot of CI time/cost

info.yaml

• adds lots of new info.yaml fields see schema docs for more information
• these are all very much up for debate. For example, I don't love the structured metadata object-style ones so there might be a better way to handle that
• none of the new fields are being rendered in the UI (yet), it felt like we should agree on the schema first

[philmillman]

@TomWhitwell @chrisgjohnson the info.yaml schema itself is very much up for debate

[jandevires71]

Elaborate, but cool if this is going to work. Could maybe even used to generate these mapping svg's automatically, which up till now I've been too lazy to create 😓 .

I know it's always hard to setup these kind of meta data things. But if you're going to do this, maybe it also time to add some linting tool and check if the existing and new info.yaml are matching the definition. And maybe run them on each new MR, before accepting. I think most people using LLM's or code harnesses will have no trouble adding these and it could lead to great and up-to-date documentation for each project.

Nice initiative! 🙌🏻

[philmillman]

Yeah that's the plan! I opened this initial draft as a way of getting public comments and once we land on the shape of the schema I can add some tooling for linting, etc.

[jandevires71]

Centralized? Would also be very cool.

[philmillman]

Yeah, it will deploy whatever you put in the /web folder (by default) with the option to override that folder and the entrypoint (defaults to index.html)

[chrisgjohnson]

Though I agree with "none of the new fields are being rendered in the UI (yet), it felt like we should agree on the schema first", I wonder if it would be worth thinking explicitly about use cases and maybe even testing with some quick vibe-coded prototypes , before finalising a yaml spec.

On that note, is the name field needed? In your example it always (?) mirrors the ID, but do you anticipate cases where ID, name and description are all distinct?

[philmillman]

Though I agree with "none of the new fields are being rendered in the UI (yet), it felt like we should agree on the schema first", I wonder if it would be worth thinking explicitly about use cases and maybe even testing with some quick vibe-coded prototypes , before finalising a yaml spec.

On that note, is the name field needed? In your example it always (?) mirrors the ID, but do you anticipate cases where ID, name and description are all distinct?

Yeah agreed some UI will help to see the final product, I was just trying to rein in the scope of this PR a bit in hopes of being incremental. I can add the UI stuff I tested back in if it's helpful, per Tom's suggestions from discord.

Re: name I was thinking that a card might want to assign a name that actually describes what the thing in question is doing vs the canonical WS input/control name. My example does a poor job of showing this. We could also merge name and description but I thought the terse version + a longer description would be useful.

items:
  - id: LED0
    name: LED 0
    description: Beat tick blink

could be:

items:
  - id: LED0
    name: Beat Tick
    description: flashing every time the beat ticks over (1 PPQ) 

[chrisgjohnson]

Re: name, that makes perfect sense

I agree, we are going to have to do this step-by-step as there's a lot of ground to cover to get to a working version of Tom's screenshots.

[philmillman]

Re: name, that makes perfect sense

I agree, we are going to have to do this step-by-step as there's a lot of ground to cover to get to a working version of Tom's screenshots.

updated the sample info.yaml with better name examples