set story 'flags'
you will attach 'flags' to in-story elements which can be changed by the player. The 'flag' might be as simple as an on/off toggle, a 'has seen this content' true/false, or it might include several states represented by a list.
All of these elements are recorded in a dynamic database while the game is running. You will need to decide which elements get reset to their start-state, and which will remember the player's interaction – there will be times when the game needs to know the player has seen content, even if the in-world character has not.
Every single item with a 'flag' will need some sort of story pay-off, however small. Never allow the player to suspect some interactions are just 'filler' with no consequence or acknowledgement.
use a story engine
A story engine like Ink runs it's own loop independent of your physically playable game. When you come across a flagged element in the game, the game consults the story engine and updates the database.
The story engine's decision tree will be a long list of all possible interactions, with each interaction needing to pass some conditional tests before the engine will allow the player to proceed.
Typical tests will be whether the player has done this interaction before (abridge the content and allow to skip), whether the player is carrying certain inventory (a key that opens a lock), whether other conditions are met (the player is currently 'The Sherriff' and can enter a restricted area), etc.
The list of possible interactions will flow from top to bottom, only allowing interactions that pass the conditional tests and suppressing the rest – in a game where the player selects from a menu of options (visual novel), the story engine will typically show the first 3 or 4 possible interactions, hiding the rest. The player must 'clear' items by completing the interaction, setting a new state for that content. The next time the story engine flows through the list, that item is flagged with its new state and the available options will change.
When the conditions are met allowing an interaction to complete, the game will signal to the player that this choice is possible (choice menu, object highlight, etc). If the player proceeds with the interaction, both the game and story engine update.
why Game and Story Engine are separate
The reason story engines evolved was to allow the story to progress independently of all game conditions. The game developer does not need to anticipate everything the player will try to do. Instead it will simply check its options for anything that is possible to do and signal the game to allow it.
The player can encounter any interactive element in any order. If the conditions are met, the interaction is allowed triggering the appropriate menu or cutscene.
This suggests a naturally emerging structure for the decision tree. Interactions with the most conditionals sit higher up in the list – essentially acting like a giant If/Else block of code.
An interaction that requires a key in inventory AND requires the player to be the Sheriff, sits higher on the list than an interaction that requires one of those conditions alone.
The story engine ignores what the player can't do, and offers only the (top) items the player can do.
Your Game
After many play-throughs, the player will remember how to interact with all these story elements, regardless of what content is seen in the current game. They will not need to play as the Sheriff once they have seen all the content that the Sheriff can do. They will be able to manipulate those story elements as any in-game character.
However, there will be content they can only access when they are The Sheriff, other content they can only access as The Housekeeper, and other content they access only as Little Sally, etc. This 'character' content will have most of the set-up and pay-offs mentioned above.
For example, an interactable item is a stuffed bear. Through several play-throughs the player learns the bear belongs to Little Sally, Little Sally won't stay in bed without the bear, the Housekeeper will look in the yard for the bear but she won't look in the park where the bear has been forgotten. Any character can move the bear from the park to the yard, but the player will not know to do this until they play as both Little Sally and the Housekeeper (and find the bear). There may be other ways to get the bear back to Little Sally before bedtime, but the game doesn't force any specific interactions, it just checks if the bear is present when Sally goes to bed, if not Sally will wake up and go looking for it (triggering other content).
This situation was spoofed in the film Groundhog Day with the main character running around town 'fixing' everything in a single speed run. That's not what would happen with your game since the player must complete the week as multiple characters before they can learn how everything interacts. The tasks can be completed as a single character, but the player can't learn everything as a single character.
Why I recommend Ink
Ink is my favorite story engine because it is game engine agnostic and 'writer-focused' being text/markup based. The authoring tool has an html exporter that can build a playable version of your game – at least the story part – which is way more convenient for proofreading and beta-testing than building out a functioning visual novel UI just to display choice prompts.
The best way to develop your game's 'story flow' is to play through the game, setting conditional variables and checking the choice options. The authoring tool Inky can run the story branches as you write the content, and has sophisticated tools to parse options where the flags are conditionally checked.
Ink can output straight text, becoming the bulk of your VN, with hidden tags to set scene elements (backgrounds, music, sprites according to your game engine).
It's free and open source, and has a large community of users.
