Build minimal Logic UI skeleton for page navigation

[jimmoffet]

Overview

ASSUMPTION: Unblocking user testing with the public, and delivering visible client value sooner is worth paying back a fair amount of debt later. If we're not all aligned on this, let's talk about it.

USER STORY: As a pardon office form builder, I would like to be able to decide where the next button on each page takes my form fillers, so that I can build the eligibility logic for the presidential pardon form.

Context

Optional: Any reference material or thoughts we may need for later reference, or assumptions of prior or future work that's out of scope for this story.

• Visibility logic for individual questions (such as "Have you ever served in the Military") is out of scope for this ticket, we're only delivering page navigation logic

Acceptance Criteria

Required outcomes of the story

• [ ] Form builders can create the pardon office eligibility criteria as specified in ticket #288
• [ ] Designs are here, blockers/big-lifts are discussed in design jams as early as possible
• [ ] Navigation logic handling architecture is designed to minimally serve the pardon eligibility criteria and to be progressively enhanced, not to build a giant foundation for universal logic
• [ ] Testing for these features is done when can verify that it catches foreseeable regressions to the pardon criteria, more comprehensive testing will be handled in future tickets

Research Questions

• Lots of open questions about how to serve universal/flexible/extensible logic, but we should strive for minimalism in this "skeleton" implementation. Unblocking user testing with the public and delivering visible client value sooner is worth paying back a fair amount of debt later

Tasks

Research, design, and engineering work needed to complete the story.

• [ ] To be handled on the fly in design jams

Definition of done

The "definition of done" ensures our quality standards are met with each bit of user-facing behavior we add. Everything that can be done incrementally should be done incrementally, while the context and details are fresh. If it’s inefficient or “hard” to do so, the team should figure out why and add OPEX/DEVEX backlog items to make it easier and more efficient.

• [ ] Behavior
  • [ ] Acceptance criteria met
  • [ ] Implementation matches design decisions
• [ ] Documentation
  • [ ] ADRs (/documents/adr folder)
  • [ ] Relevant README.md(s)
• [ ] Code quality
  • [ ] Code refactored for clarity and no design/technical debt
  • [ ] Adhere to separation of concerns; code is not tightly coupled, especially to 3rd party dependencies; dependency rule followed
  • [ ] Code is reviewed by team member
  • [ ] Code quality checks passed
• [ ] Security and privacy
  • [ ] Automated security and privacy gates passed
• [ ] Testing tasks completed
  • [ ] Automated tests pass
  • [ ] Unit test coverage of our code >= 90%
• [ ] Build and deploy
  • [ ] Build process updated
  • [ ] API(s) are versioned
  • [ ] Feature toggles created and/or deleted. Document the feature toggle
  • [ ] Source code is merged to the main branch

Decisions

• Optional: Any decisions we've made while working on this story

[JennyRichards-Flexion]

Other tickets will fall out of this one. Large ticket, might take ~2 weeks.

Big open question - how do we represent the rules and data. If we use a simple formalism to use the rules, there's prior art. Might be rather simple, but need to dig in. Jim is happy to jam on thinking through that.