# JSON Migration Todos
(?) denotes tasks which could be optional or need further discussion to determine if they should be performed.

- DEPLOY
	- Create staging instance of Exporter with JSON migration changes
	- Deploy app and admin with JSON migration change to staging
		- Wipe user project data
	- Deploy to prod

- TODO COMMENTS IN CODE
	- `apps/app/src/server/ai/completion-slidewriter.ts` : LINE 47 TODO...
		- hard coded iteration count, need to either dynamically calculate the number of sections or have a place where it can be configured
	- `apps/app/src/app/(app)/project/[projectId]/page.tsx` : LINE 39 TODO...
		- see database migrations
	- `apps/app/src/server/presentation-converter.ts`: LINE 198 TODO...
		- seems like we could combine all converter LLM calls in to one to avoid having to upload the same image multiple times
	- `apps/app/src/hooks/use-ai-completion.ts`: LINE 65 TODO...
		- sometimes unparsable JSON objects are streamed to the front end and it triggers a warning message that can happen many times consectively...I believe it should be supressed when called more than once in a short period

- DATABASE MIGRATION
	- Remove either `completion` or `completionJson` and store completion object in one (currently using `completionJson`)
	- (?) Update `LlmCall` to track completion pass number, and maybe more?
	- (?) Add new table for tracking completion requests that make more than one llm call...chain completions and completions that fail to validate and require multiple passes make more than one llm call

- CLEAN UP
	- (?) Make front end components be able to natively handle JSON objects instead of having to convert the object...
		- To render tables we need to convert to `TableWithCellIds` or `TableWithRowIds`
		- To render storymap we need to convert to `Section[]`
		- To generate outline we convert to `Storyline` (this is already very similar to `OutlineCompletion`)
		- (Counter) It shouldn't be that expensive to just convert the data, is this worth doing?
	- (?) Better logging/debug data?
		- Track completion passes in `LlmCall`?
		- More info dumps to track what app is doing?
	- (?) Move completion types to `packages/db` to go alignside prompt types and schemas. ...So they can be accessed by admin app?
		- Admin doesn't really need awareness of the completion types, it just dumps them as JSON.

- CLI
	- (?) Expand CLI to support storyline project types

- QUESTIONS / THOUGHTS
	- Is 'completion' the best name for the LLM JSON objects?
	- Is the LLM required to populate every placeholder in a layout? If not which ones should be required? (Title, etc)
	- How should we handle streaming completions when they fail validation?
		- The user will see the data completely reset and it will likely be very confusing.
		- Idea...an overlay briefly pops up with a message like "The content failed to pass quality control, hang tight while we regenerate it"
	- Is there a better way we could represent user inputs in admin?
		- It would be neat if the user's selections were highlighted in the JSON display
	- Currently using 'completion-to-Markdown' functions to inject completion data in to prompts, is this nessecary? Could we just JSON stringify the data?
	- Updated step input to reference data via ids/indexes. Is this sufficent? Are there any reasons why this might not have been a good idea?
		- For `TableWithCellIds` the inputs are now a list of string following this format: `[heading name].[row index]` ... i.e. `challenges.0`, `opportunities.2`
		- For `TableWithRowIds` this is now just a number of list of numbers (depending if multi-select or not) of the selected row index(es)
		- For receptiveness this is just the literal string "curious" or "resistant"
		- Audience summary is unchanged.
		- Main reasons for these changes...
			- with JSON objects I felt there was no longer a need to store the full text string of the values the user selected, just indexes pointing to the completion would suffice
			- I wanted this to be easilly readable when looking at it in the database for future debugging