feat(console): initial tui for component-defn read

[meganwolf0]

Description

Initial TUI Experimentation for read-only operations on component-defn OSCAL model

Related Issue

Fixes #

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Other (security config, docs update, etc)

Checklist before merging

• Test, docs, adr added or updated as needed
• Schema Updates applied
• Contributor Guide Steps followed

[meganwolf0]

Looking for a review on the read-only component-definition features, still need to add some docs - any thought as to where those should go?

[brandtkeller]

Appreciative of functionality that thinks about the OSCAL as more than just the scope of NIST 800-53.

[brandtkeller]

Is there any common testing patterns for this model of TUI?

Open to making that a separate deliverable but I imagine we will begin hitting many edge cases where a separation of how the model is visualized is separate from unit testing functions.

[meganwolf0]

Is there any common testing patterns for this model of TUI?

hmmm maybe we could look at adding VHS for testing - might need a human to review the gifs but possibly better than nothing? Looks like this teatest library kind of exists, but the fine print on the repo doesn't guarantee any backward compatibility or future support...

[brandtkeller]

Is there any common testing patterns for this model of TUI?

hmmm maybe we could look at adding VHS for testing - might need a human to review the gifs but possibly better than nothing? Looks like this teatest library kind of exists, but the fine print on the repo doesn't guarantee any backward compatibility or future support...

I'd lean towards TeaTest given that we manage that dependency accordingly. I'd like to review capabilities (again maybe a separate issue) and annotate gaps -> maybe there is room to contribute back.

[meganwolf0]

I'd lean towards TeaTest given that we manage that dependency accordingly. I'd like to review capabilities (again maybe a separate issue) and annotate gaps -> maybe there is room to contribute back.

Ok that's fair. Is that something you'd like me to try and incorporate in this PR or write another issue (file it under tech debt haha) and tackle later? Just trying to make sure there's nothing remaining in my actions list on this one

[brandtkeller]

Removes the need for that argument check ,improves native cobra flow and should provide more input validation.

So I was thinking about this more and wondering if that truly is more "native cobra" - as the Run command expects args and this will not run without that argument, so I'm wondering why is it bad to have that check (len(args)==0) ? I agree that it's more aligned with our other usage of flags, but also wondering if we should think more about the conventions we've set up for ourselves. If we are constantly having to put -f for a completely mandatory input, is that really desirable? Should flags be more in the realm of optional or intended to have alternative behaviors or additional functionality, as opposed to enforcing mandatory fields (e.g., file inputs)...

Anyway, I can change this, it's more just a thought about why/when to use flags vs args.

"native cobra" may not be fully capturing intent - but I do want to be iterating towards both flags and args having more strict control using cobra builtins such that we're improving our intended user experience without having to instrument that behavior for each command.

Things such as combining required flag definitions with different permutations of argument use such that the pattern improves.

[brandtkeller]

I'd lean towards TeaTest given that we manage that dependency accordingly. I'd like to review capabilities (again maybe a separate issue) and annotate gaps -> maybe there is room to contribute back.

Ok that's fair. Is that something you'd like me to try and incorporate in this PR or write another issue (file it under tech debt haha) and tackle later? Just trying to make sure there's nothing remaining in my actions list on this one

New issue to track testing -> would like to gauge interest in getting the testing structure in place prior to additional TUI feature development.

[meganwolf0]

For posterity, #627 opened to address testing

[brandtkeller]

Minor comments but otherwise love the direction this sets.

The current structure I believe lends itself well to current thoughts around reporting - where we might be able to pass in multiple OSCAL files and establish an oscalModel that contains a valid artifact for each model (maybe this is multiple -f flags populating the full oscalModel object etc).

This creates a wholistic context of how the pieces connect to one-another and the ability to execute actions (validate etc) from this view will be fun to pursue.

[brandtkeller]

Maybe last item: Can you switch log_level to info in the lula-config.yaml and run:

./bin/lula internal gen-cli-docs

Should only create a doc for the new console command.