Consolidate all recipe development docs

[bfollington]

• Move docs into labs from recipes repo (see https://github.com/commontoolsinc/recipes/pull/47)
• Include docs/common when running ct init

---

Summary by cubic

Consolidated all recipe development docs under docs/common and updated references for a single, consistent source of truth (addresses CT-815). ct init now bundles these docs and copies them to .ct-docs for easy, offline access.

• New Features

  • ct init copies docs/common to .ct-docs in new workspaces.
  • Build includes docs/common in the compiled CLI binary.
  • Added docs: RECIPES.md, HANDLERS.md, COMPONENTS.md; moved CT.md.

• Refactors

  • Updated commands, agents, and README to point to docs/common/CT.md.
  • Adjusted scripts to search docs in docs/common instead of recipes/.
  • Minor doc cleanups for consistency and links.

[linear]

CT-815 Review .md docs for inconsistencies

[bfollington]

@jsantell tagging you because I thought of a potentially clever/stupid idea: I made ct init copy the contents of the (newly formed) docs/common into a .ct-docs folder.

Previously, these files were in our recipes repo but we elected that they belong in labs after discussion. These files were designed for 'end users' who are developing recipes themselves and our recipes repo is our attempt to simulate that, so I think having ct able to bundle the docs may be the best of both worlds?

This is but one part of a broad effort to clean up our .md files.

[jsantell]

looks good! handful of comments

[jsantell]

Typing these events would go a long way it seems, let's talk more on how we can do this

[bfollington]

Yah I don't know how to make the types easily available, but odds are most of the events take the shape:

type CommonEvent<T> = {
  detail: T
}

[seefeldb]

And this is a bit to be congruent with DOM events, but we should discuss whether we really want to carry this over to events that are clearly not DOM. Any thoughts?

[bfollington]

For the ct- components it seems reasonable to use detail and since these sometimes appear in a lit context outside of recipes where DOM conventions are expected?

Regardless of structure, what we need to do is associate the event types with the onClick etc. bindings via jsx.d.ts somehow so the handlers can infer the type... Seems tricky but possible.