docs: decide feature granularity and folder structure for inc_time module

[lavrovvalera]

Context

Issue #40 requires the module to comply with SCORE folder and naming conventions (folder.rst, naming.rst). Before implementing any structural changes, a conceptual decision is needed: what counts as a "feature" in this module?

The folder structure depends entirely on this answer, because docs/features/<feature_name>/ must be named after user-visible capabilities — not implementation components.

Once decided, the implementation shall be done according to folder.rst and naming.rst conventions. Issue #84 shall be refined based on the decision made in this ticket.

---

Problem

The module currently has three folders under docs/features/:

docs/features/time/         ← named after component
docs/features/time_daemon/  ← named after component  
docs/features/time_slave/   ← named after component

Per folder.rst, feature folders must represent user-visible capabilities, not implementation components. Additionally, docs/features/*/architecture/ sub-folders are missing everywhere — content sits flat under _assets/.

---

Decision needed

1. How many features does inc_time implement? Option A (three independent features) or Option B (one feature)?
2. If Option A: are the proposed feature names correct?

---

Option A — Three features

vehicle_time and local_clock have different component dependencies and deployment models. A user can use local_clock with zero daemon or slave process deployed. They are independently useful and independently deployable.

inc_time/
├── docs/
│   ├── features/
│   │   ├── vehicle_time/            ← gPTP-synced time + status API
│   │   │   └── architecture/          components: time_slave + time_daemon + vehicle_time API
│   │   ├── local_clock/             ← OS-backed clocks, no sync infrastructure
│   │   │   └── architecture/          components: time API only
│   │   │                              (SteadyTime, SystemTime, HighResSteadyTime, HplsTime)
│   │   └── abs_time/                ← UTC-synced absolute time (future placeholder)
│   │       └── architecture/          components: time_daemon + time API + TBD
│   ├── manuals/
│   ├── release/
│   ├── safety_mgt/
│   ├── security_mgt/
│   └── verification_report/
└── score/
    ├── time/                        ← component: Clock<Tag> API library
    │   ├── docs/
    │   │   ├── requirements/
    │   │   ├── detailed_design/
    │   │   └── architecture/
    │   └── src/
    ├── time_daemon/                 ← component: TimeDaemon
    │   ├── docs/
    │   │   ├── requirements/
    │   │   ├── detailed_design/
    │   │   └── architecture/
    │   └── src/
    ├── time_slave/                  ← component: TimeSlave (already compliant)
    │   ├── docs/
    │   │   ├── requirements/
    │   │   ├── detailed_design/
    │   │   ├── architecture/
    │   │   ├── manuals/
    │   │   ├── safety_analysis/
    │   │   └── security_analysis/
    │   ├── src/
    │   └── tests/
    └── ts_client/                   ← component: IPC client library
        ├── docs/
        │   ├── requirements/
        │   └── detailed_design/
        └── src/

---

Option B — One feature

The central score platform repo defines everything under one feature score/docs/features/time/. The module follows the single-feature variant from folder.rst, omitting the features/ nesting level.

inc_time/
├── docs/
│   ├── architecture/                ← single feature architecture, covers all
│   │   └── _assets/                   capabilities (vehicle_time, local_clock,
│   │                                   abs_time) in one document
│   ├── manuals/
│   ├── release/
│   ├── safety_mgt/
│   ├── security_mgt/
│   └── verification_report/
└── score/
    ├── time/                        ← component: Clock<Tag> API library
    │   ├── docs/
    │   │   ├── requirements/
    │   │   ├── detailed_design/
    │   │   └── architecture/
    │   └── src/
    ├── time_daemon/                 ← component: TimeDaemon
    │   ├── docs/
    │   │   ├── requirements/
    │   │   ├── detailed_design/
    │   │   └── architecture/
    │   └── src/
    ├── time_slave/                  ← component: TimeSlave (already compliant)
    │   ├── docs/
    │   │   ├── requirements/
    │   │   ├── detailed_design/
    │   │   ├── architecture/
    │   │   ├── manuals/
    │   │   ├── safety_analysis/
    │   │   └── security_analysis/
    │   ├── src/
    │   └── tests/
    └── ts_client/                   ← component: IPC client library
        ├── docs/
        │   ├── requirements/
        │   └── detailed_design/
        └── src/

---

Additional note on content placement

Regardless of which option is chosen, the existing docs/features/time_daemon/_assets/ and docs/features/time_slave/_assets/ content (internal class diagrams, internal sequences for ptp_machine, msg_broker, ipc, etc.) is component detailed design, not feature architecture. It belongs in score/<component>/docs/detailed_design/, not in the feature folder.

---

References

• SCORE folder conventions: https://github.com/eclipse-score/score/blob/main/docs/contribute/general/folder.rst
• SCORE naming conventions: https://github.com/eclipse-score/score/blob/main/docs/contribute/general/naming.rst
• SCORE architecture guideline: https://eclipse-score.github.io/process_description/main/process_areas/architecture_design/guidance/architecture_guideline.html

[BjoernAtBosch]

I'd vote for one feature (option B): Time is currently considered as a (single) feature in S-CORE main documentation (see https://eclipse-score.github.io/score/main/features/time/index.html). I'd keep this and handle the time lib, time_slave, time_daemon, etc as components. They are not useful standalone, so I wouldn't see them as separate features.

[BlueXMarv3l]

I vote for Option B — a single feature structure fits better here. Those components are more like capabilities within a time feature than separate top-level features, and this aligns better with SCORE’s feature-oriented folder conventions.