Concept ClockScope for using ScriptableObject

[xchesh]

No description provided.

[Copilot]

Pull request overview

This PR refactors the clock system to use Unity's ScriptableObject pattern for configuration. It replaces the simple ClockModel with a more flexible ClockService that supports configurable time offsets, introducing a separation of concerns between service logic and configuration data.

• Renamed IClockModel to IClockService and replaced ClockModel with ClockService that accepts configuration
• Introduced ClockConfig as a ScriptableObject with IClockConfig interface for time offset configuration
• Added ClockScope MonoBehaviour to bridge Unity's serialization system with the dependency injection framework

Reviewed changes

Copilot reviewed 15 out of 17 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
IClockService.cs	Renamed interface from IClockModel to IClockService
IClockConfig.cs	New interface defining configuration contract with TimeSpan Offset property
ClockService.cs	New service implementation that uses IClockConfig to apply time offset
ClockScope.cs	MonoBehaviour that exposes serialized ClockConfig to the DI system
ClockConfig.cs	ScriptableObject implementation of IClockConfig with serialized offset seconds
Composition.cs	Updated DI bindings to wire up IClockConfig and ClockService as singleton
Clock.cs	Updated to use IClockService instead of IClockModel
ClockModel.cs	Removed - replaced by ClockService
ClockConfig.asset	Unity asset file with default 360 second offset configuration
Resources.meta	Unity metadata for Resources folder
*.meta files	Unity metadata files for all new scripts

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

This binding creates a potential circular dependency. The IClockConfig binding injects ClockScope, but ClockScope.Start() calls Composition.Shared.BuildUp(this), which may attempt to resolve dependencies during injection. This could lead to runtime errors or infinite loops. Consider refactoring to avoid this circular dependency, such as making ClockScope register itself with the composition root instead of using injection here.

[Copilot]

The binding does not specify the interface type it's binding to. While this may work due to type inference, it's inconsistent with the explicit binding pattern used for IClockConfig on line 10. Consider using .Bind<IClockService>() for consistency and clarity.

Suggested change

	.Bind().As(Singleton).To<ClockService>()
	.Bind<IClockService>().As(Singleton).To<ClockService>()

[Copilot]

The _config field could be null if not assigned in the Unity Inspector. Consider adding a null check when accessing Config to prevent NullReferenceException, or validate that _config is not null in an Awake or Start method.

[Copilot]

The BuildUp call appears unnecessary as ClockScope doesn't have any properties marked with [Dependency] attribute. This call adds overhead without providing value. Consider removing it unless dependencies will be added in the future.

Suggested change

	void Start()
	{
	// Injects dependencies
	Composition.Shared.BuildUp(this);
	}

[Copilot]

The config parameter and _config field should be validated for null to prevent NullReferenceException when accessing _config.Offset in the Now property. Consider adding a null check in the constructor or throwing an ArgumentNullException if config is null.

Suggested change

	_config = config;
	_config = config ?? throw new ArgumentNullException(nameof(config));