Files

168 lines
40 KiB
HTML

<!doctype html>
<html lang="en">
<head><meta charset="utf-8" /><title>Container boundary: apps/nrf52_node</title></head>
<body>
<main class="praxis-architecture-map" data-praxis-anchor="architecture:c4:container:apps-nrf52_node" data-praxis-kind="architecture_c4_container" data-praxis-status="candidate" data-praxis-confidence="high" data-praxis-document-path="docs/architecture/c4/containers/apps-nrf52_node/container.html" data-praxis-drilldowns="[{&quot;id&quot;:&quot;architecture:c4:component:apps-nrf52_node&quot;,&quot;level&quot;:&quot;component&quot;,&quot;title&quot;:&quot;Component responsibility: apps/nrf52_node&quot;,&quot;summary&quot;:&quot;Explain the key responsibility units inside apps/nrf52_node from the C4 Component layer: entry, page, command, interface, registry, adapter or shared object.&quot;,&quot;docPath&quot;:&quot;docs/architecture/c4/components/apps-nrf52_node/component.md&quot;,&quot;htmlPath&quot;:&quot;docs/architecture/c4/components/apps-nrf52_node/component.html&quot;,&quot;anchor&quot;:&quot;architecture:c4:component:apps-nrf52_node&quot;,&quot;relation&quot;:&quot;contains&quot;,&quot;reason&quot;:&quot;Enter Component responsibility: apps/nrf52_node can answer \&quot;Container boundary: which internal components are hosted by apps/nrf52_node\&quot;. Focus on portals, orchestration, adaptation, contracts, and shared objects rather than browsing the entire file.&quot;},{&quot;id&quot;:&quot;architecture:c4:code:apps-nrf52_node&quot;,&quot;level&quot;:&quot;code&quot;,&quot;title&quot;:&quot;Code anchor point: apps/nrf52_node&quot;,&quot;summary&quot;:&quot;Explain a few key code anchors in apps/nrf52_node from the C4 Code layer. The Code layer is not a code browser and is only used when you need to understand how architectural components fall into specific files/symbols.&quot;,&quot;docPath&quot;:&quot;docs/architecture/c4/code/apps-nrf52_node/code.md&quot;,&quot;htmlPath&quot;:&quot;docs/architecture/c4/code/apps-nrf52_node/code.html&quot;,&quot;anchor&quot;:&quot;architecture:c4:code:apps-nrf52_node&quot;,&quot;relation&quot;:&quot;details&quot;,&quot;reason&quot;:&quot;Enter code anchor point: apps/nrf52_node to trace the architectural responsibility of container boundary: apps/nrf52_node to the specific file/symbol anchor point; only when you need to determine the implementation entry or the impact of the change, you should drill down to Code.&quot;}]">
<header class="praxis-design-map-header">
<p>Praxis Architecture View</p>
<h1>Container boundary: apps/nrf52_node</h1>
<p>apps/nrf52_node is a C4 Container layer candidate boundary: it must appear as an application, service, data store, runnable unit, or independently deployable/executable system part, rather than a normal directory, code layering, or shared collection of tools.</p>
<div class="meta-row">
<span>Container</span>
<span>candidate / high</span>
<span>0.1.30-alpha · 34aad0bffa2f / main</span>
</div>
</header>
<section class="semantic-layer" data-praxis-anchor="architecture:c4:layer-path" data-praxis-kind="architecture_c4_list">
<h2>C4 hierarchy path</h2>
<ul>
<li>Current layer: Container, which explains an independently understandable application, service, data storage or running unit within the target system.</li>
<li>Upper layer: System Context, indicating which target software system the Container belongs to.</li>
<li>Lower layer: Component, explaining the entrance, interface, orchestration, adaptation, contract or shared object inside the Container.</li>
</ul>
</section>
<section class="semantic-layer" data-praxis-anchor="architecture:c4:responsibility" data-praxis-kind="architecture_c4_text">
<h2>Responsibility</h2>
<p>apps/nrf52_node is an application-level Container candidate: warehouse evidence shows it is close to a runnable entry, a desktop/front-end/back-end application shell, or a user-perceivable system capability.</p>
</section>
<section class="semantic-layer" data-praxis-anchor="architecture:c4:boundary" data-praxis-kind="architecture_c4_text">
<h2>Boundary</h2>
<p>The boundary comes from the warehouse path apps/nrf52_node. C4 Container is not equal to any package or code layer; only boundaries with applications, services, data storage, runtime portals, deployment units, external interfaces or independent execution semantics enter this layer. Ordinary configuration files, document directories, CI directories, warehouse management files and pure code layering can only be used as evidence or software structure model objects, not as Containers.</p>
</section>
<section class="semantic-layer" data-praxis-anchor="architecture:c4:relationships" data-praxis-kind="architecture_c4_list">
<h2>Relationship</h2>
<ul>
<li>Depends on other Containers: apps/esp32_lvgl, apps/linux_uconsole_gtk, apps/linux_cardputer_zero.</li>
<li>Contains 14 candidate component view objects, 0 run/collaboration links, and 0 run or build nodes.</li>
</ul>
</section>
<section class="semantic-layer" data-praxis-anchor="architecture:c4:business-relation" data-praxis-kind="architecture_c4_list">
<h2>Relationship with business complexity</h2>
<ul>
<li>This Container is not the business use case itself; it only explains the internal application/service/data storage/operation unit of the software system through which the business capability enters or passes.</li>
<li>If the Use Case in the organization/process model refers to this boundary, how it enters this Container should be explained in the Use Case drill-down document instead of writing the business process into the C4 Container diagram.</li>
</ul>
</section>
<section class="semantic-layer" data-praxis-anchor="architecture:c4:engineering-relation" data-praxis-kind="architecture_c4_list">
<h2>Relationship with technical complexity</h2>
<ul>
<li>Corresponds to the software structure model Package Diagram: docs/engineering/package-diagrams/apps-nrf52_node/package-diagram.html.</li>
<li>Continue to enter the software structure model to view drill-down UML, structural collaboration, running links and complexity candidate points.</li>
</ul>
</section>
<section class="semantic-layer diagram-section" data-praxis-anchor="architecture:c4:diagram" data-praxis-kind="architecture_c4_diagram">
<h2>C4 Container diagram</h2>
<pre class="mermaid" data-praxis-anchor="architecture:c4:container:apps-nrf52_node:c4" data-praxis-c4-current-level="container" data-praxis-c4-layer-views="[{&quot;level&quot;:&quot;system_context&quot;,&quot;label&quot;:&quot;System Context&quot;,&quot;title&quot;:&quot;System Context: trail-mate&quot;,&quot;diagramTitle&quot;:&quot;C4 System Context Diagram&quot;,&quot;summary&quot;:&quot;System Context only shows the relationship between the target software system and external people/systems, and does not directly expand the internal Container; what is highlighted here is the boundary of the software system to which \&quot;apps/nrf52_node\&quot; belongs.&quot;,&quot;docPath&quot;:&quot;docs/architecture/c4/system-context/system-context.md&quot;,&quot;htmlPath&quot;:&quot;docs/architecture/c4/system-context/system-context.html&quot;,&quot;mermaid&quot;:&quot;flowchart LR\n actor[\&quot;Unnamed external actor\&quot;]\n system[\&quot;trail-mate\&quot;]\n external[\&quot;Unnamed external system\&quot;]\n actor --&gt;|Use / Call| system\n system -.-&gt;|Candidate Integration| external&quot;,&quot;highlightLabels&quot;:[&quot;apps/nrf52_node&quot;,&quot;apps/nrf52_node Container&quot;,&quot;apps/nrf52_node (system internal Container)&quot;,&quot;nrf52_node&quot;,&quot;trail-mate&quot;],&quot;current&quot;:false,&quot;missing&quot;:false},{&quot;level&quot;:&quot;container&quot;,&quot;label&quot;:&quot;Container&quot;,&quot;title&quot;:&quot;Container boundary: apps/nrf52_node&quot;,&quot;diagramTitle&quot;:&quot;C4 Container diagram&quot;,&quot;summary&quot;:&quot;Currently reading the Container layer; the formal diagram below is the architectural projection of this layer.&quot;,&quot;docPath&quot;:&quot;docs/architecture/c4/containers/apps-nrf52_node/container.md&quot;,&quot;htmlPath&quot;:&quot;docs/architecture/c4/containers/apps-nrf52_node/container.html&quot;,&quot;mermaid&quot;:&quot;flowchart LR\n container[\&quot;apps/nrf52_node\&quot;]\n dependency_1[\&quot;apps/esp32_lvgl\&quot;]\n container --&gt; dependency_1\n dependency_2[\&quot;apps/linux_uconsole_gtk\&quot;]\n container --&gt; dependency_2\n dependency_3[\&quot;apps/linux_cardputer_zero\&quot;]\n container --&gt; dependency_3&quot;,&quot;highlightLabels&quot;:[&quot;apps/nrf52_node&quot;,&quot;apps/nrf52_node Container&quot;,&quot;apps/nrf52_node (system internal Container)&quot;,&quot;nrf52_node&quot;],&quot;current&quot;:true,&quot;missing&quot;:false},{&quot;level&quot;:&quot;component&quot;,&quot;label&quot;:&quot;Component&quot;,&quot;title&quot;:&quot;Component responsibility: apps/nrf52_node&quot;,&quot;diagramTitle&quot;:&quot;C4 Component diagram&quot;,&quot;summary&quot;:&quot;When switching to the Component layer, the corresponding position of \&quot;apps/nrf52_node\&quot; in the official document of this layer will be highlighted.&quot;,&quot;docPath&quot;:&quot;docs/architecture/c4/components/apps-nrf52_node/component.md&quot;,&quot;htmlPath&quot;:&quot;docs/architecture/c4/components/apps-nrf52_node/component.html&quot;,&quot;mermaid&quot;:&quot;flowchart TB\n container[\&quot;apps/nrf52_node Container\&quot;]\n component_1[\&quot;ChatService\&quot;]\n container --&gt; component_1\n component_2[\&quot;ContactService\&quot;]\n container --&gt; component_2\n component_3[\&quot;IMeshAdapter\&quot;]\n container --&gt; component_3\n component_4[\&quot;ScopedGpsSuspend\&quot;]\n container --&gt; component_4\n component_5[\&quot;AppFacadeRuntime\&quot;]\n container --&gt; component_5\n component_6[\&quot;ChatModel\&quot;]\n container --&gt; component_6\n component_7[\&quot;SelfIdentityBridge\&quot;]\n container --&gt; component_7\n component_8[\&quot;IChatStore\&quot;]\n container --&gt; component_8\n component_9[\&quot;IContactStore\&quot;]\n container --&gt; component_9\n component_10[\&quot;INodeStore\&quot;]\n container --&gt; component_10&quot;,&quot;highlightLabels&quot;:[&quot;apps/nrf52_node&quot;,&quot;apps/nrf52_node Container&quot;,&quot;apps/nrf52_node (system internal Container)&quot;,&quot;nrf52_node&quot;],&quot;current&quot;:false,&quot;missing&quot;:false},{&quot;level&quot;:&quot;code&quot;,&quot;label&quot;:&quot;Code&quot;,&quot;title&quot;:&quot;Code anchor point: apps/nrf52_node&quot;,&quot;diagramTitle&quot;:&quot;C4 Code View diagram&quot;,&quot;summary&quot;:&quot;When switching to the Code layer, the corresponding position of \&quot;apps/nrf52_node\&quot; in the official document of this layer will be highlighted.&quot;,&quot;docPath&quot;:&quot;docs/architecture/c4/code/apps-nrf52_node/code.md&quot;,&quot;htmlPath&quot;:&quot;docs/architecture/c4/code/apps-nrf52_node/code.html&quot;,&quot;mermaid&quot;:&quot;flowchart TB\n package[\&quot;apps/nrf52_node\&quot;]\n file_1[\&quot;apps/nrf52_node/src/nrf52_node_app_facade_runtime.cpp\&quot;]\n code_1[\&quot;AppFacadeRuntime::getTeamController\&quot;]\n package --&gt; file_1\n file_1 --&gt; code_1\n file_2[\&quot;apps/nrf52_node/src/nrf52_node_app_facade_runtime.h\&quot;]\n code_2[\&quot;ChatService\&quot;]\n package --&gt; file_2\n file_2 --&gt; code_2\n file_3[\&quot;apps/nrf52_node/src/nrf52_node_app_facade_runtime.h\&quot;]\n code_3[\&quot;ContactService\&quot;]\n package --&gt; file_3\n file_3 --&gt; code_3\n file_4[\&quot;apps/nrf52_node/src/nrf52_node_app_facade_runtime.h\&quot;]\n code_4[\&quot;IMeshAdapter\&quot;]\n package --&gt; file_4\n file_4 --&gt; code_4\n file_5[\&quot;apps/nrf52_node/src/nrf52_node_app_facade_runtime.cpp\&quot;]\n code_5[\&quot;&amp; AppFacadeRuntime::getChatService()\&quot;]\n package --&gt; file_5\n file_5 --&gt; code_5\n file_6[\&quot;apps/nrf52_node/src/nrf52_node_app_facade_runtime.cpp\&quot;]\n code_6[\&quot;&amp; AppFacadeRuntime::getContactService()\&quot;]\n package --&gt; file_6\n file_6 --&gt; code_6\n file_7[\&quot;apps/nrf52_node/src/nrf52_node_app_facade_runtime.cpp\&quot;]\n code_7[\&quot;AppFacadeRuntime::getMeshAdapter\&quot;]\n package --&gt; file_7\n file_7 --&gt; code_7\n file_8[\&quot;apps/nrf52_node/src/nrf52_node_app_facade_runtime.cpp\&quot;]\n code_8[\&quot;AppFacadeRuntime::getMeshAdapter\&quot;]\n package --&gt; file_8\n file_8 --&gt; code_8&quot;,&quot;highlightLabels&quot;:[&quot;apps/nrf52_node&quot;,&quot;apps/nrf52_node Container&quot;,&quot;apps/nrf52_node (system internal Container)&quot;,&quot;nrf52_node&quot;],&quot;current&quot;:false,&quot;missing&quot;:false}]">flowchart LR
container[&quot;apps/nrf52_node&quot;]
dependency_1[&quot;apps/esp32_lvgl&quot;]
container --&gt; dependency_1
dependency_2[&quot;apps/linux_uconsole_gtk&quot;]
container --&gt; dependency_2
dependency_3[&quot;apps/linux_cardputer_zero&quot;]
container --&gt; dependency_3</pre>
</section>
<section class="semantic-layer architecture-c4-elements" data-praxis-anchor="architecture:c4:container:apps-nrf52_node:elements" data-praxis-kind="architecture_c4_elements">
<h2>Explanation of elements in the diagram</h2>
<div class="layer-grid">
<article class="layer-card" data-praxis-anchor="architecture:c4:container:apps-nrf52_node:self" data-praxis-kind="architecture_c4_element" data-praxis-confidence="high" data-praxis-drilldowns="[{&quot;id&quot;:&quot;architecture:c4:component:apps-nrf52_node&quot;,&quot;level&quot;:&quot;component&quot;,&quot;title&quot;:&quot;Component responsibility: apps/nrf52_node&quot;,&quot;summary&quot;:&quot;Explain the key responsibility units inside apps/nrf52_node from the C4 Component layer: entry, page, command, interface, registry, adapter or shared object.&quot;,&quot;docPath&quot;:&quot;docs/architecture/c4/components/apps-nrf52_node/component.md&quot;,&quot;htmlPath&quot;:&quot;docs/architecture/c4/components/apps-nrf52_node/component.html&quot;,&quot;anchor&quot;:&quot;architecture:c4:component:apps-nrf52_node&quot;,&quot;relation&quot;:&quot;contains&quot;,&quot;reason&quot;:&quot;Enter Component responsibility: apps/nrf52_node can answer \&quot;Container boundary: which internal components are hosted by apps/nrf52_node\&quot;. Focus on portals, orchestration, adaptation, contracts, and shared objects rather than browsing the entire file.&quot;},{&quot;id&quot;:&quot;architecture:c4:code:apps-nrf52_node&quot;,&quot;level&quot;:&quot;code&quot;,&quot;title&quot;:&quot;Code anchor point: apps/nrf52_node&quot;,&quot;summary&quot;:&quot;Explain a few key code anchors in apps/nrf52_node from the C4 Code layer. The Code layer is not a code browser and is only used when you need to understand how architectural components fall into specific files/symbols.&quot;,&quot;docPath&quot;:&quot;docs/architecture/c4/code/apps-nrf52_node/code.md&quot;,&quot;htmlPath&quot;:&quot;docs/architecture/c4/code/apps-nrf52_node/code.html&quot;,&quot;anchor&quot;:&quot;architecture:c4:code:apps-nrf52_node&quot;,&quot;relation&quot;:&quot;details&quot;,&quot;reason&quot;:&quot;Enter code anchor point: apps/nrf52_node to trace the architectural responsibility of container boundary: apps/nrf52_node to the specific file/symbol anchor point; only when you need to determine the implementation entry or the impact of the change, you should drill down to Code.&quot;}]">
<h3>apps/nrf52_node</h3>
<p>Container · high</p>
<p>This node in the diagram represents apps/nrf52_node, the C4 Container; the current document records 14 component drill-down entries, 0 running collaboration threads and 0 running or build nodes.</p>
<dl>
<div><dt>Responsibility</dt><dd>apps/nrf52_node is an application-level Container candidate: warehouse evidence shows it is close to a runnable entry, a desktop/front-end/back-end application shell, or a user-perceivable system capability.</dd></div>
<div><dt>Boundary</dt><dd>The boundary comes from the warehouse path apps/nrf52_node; the entry, service interface, application code, running configuration and deployment evidence under this path jointly support it to enter the Container layer. Ordinary configuration files, document directories or pure code layers will not form a Container alone.</dd></div>
<div><dt>Relationship meaning</dt><dd>The figure points from apps/nrf52_node to the external boundary, indicating that this runnable boundary will call, reference or depend on other Containers; these relationships are used to determine deployment, interfaces and change impacts.</dd></div>
<div><dt>Why it belongs to this layer</dt><dd>The node enters the Container layer because the local warehouse evidence shows that it has applications, services, data storage, running portals, deployment units, external interfaces, or independent execution semantics; not because it is just a directory or package.</dd></div>
<div><dt>Drill-down intention</dt><dd>Drill down from apps/nrf52_node to Component to view the decomposition of responsibilities within the boundary.</dd></div>
</dl>
</article>
<article class="layer-card" data-praxis-anchor="architecture:c4:container:apps-nrf52_node:dep:apps-esp32_lvgl" data-praxis-kind="architecture_c4_element" data-praxis-confidence="medium" data-praxis-drilldowns="[]">
<h3>apps/esp32_lvgl</h3>
<p>Container · medium</p>
<p>apps/nrf52_node depends on apps/esp32_lvgl.</p>
<dl>
<div><dt>Responsibility</dt><dd>apps/nrf52_node depends on apps/esp32_lvgl.</dd></div>
<div><dt>Boundary</dt><dd>apps/esp32_lvgl does not belong to the internal boundaries of apps/nrf52_node; it is only a dependent adjacent module in the current graph.</dd></div>
<div><dt>Relationship meaning</dt><dd>apps/nrf52_node -> apps/esp32_lvgl indicates that there are cross-border calls, references or configuration dependencies in the local warehouse evidence; it illustrates the direction of technical collaboration, but cannot independently prove the business process relationship.</dd></div>
<div><dt>Why it belongs to this layer</dt><dd>apps/esp32_lvgl is projected as an adjacent Container candidate by path ownership, rather than apps/nrf52_node internal Component.</dd></div>
<div><dt>Drill-down intention</dt><dd>Enter the independent Container document of apps/esp32_lvgl to view its own responsibilities and evidence; if there is no independent document, it will only be regarded as an external dependency fact.</dd></div>
</dl>
</article>
<article class="layer-card" data-praxis-anchor="architecture:c4:container:apps-nrf52_node:dep:apps-linux_uconsole_gtk" data-praxis-kind="architecture_c4_element" data-praxis-confidence="medium" data-praxis-drilldowns="[]">
<h3>apps/linux_uconsole_gtk</h3>
<p>Container · medium</p>
<p>apps/nrf52_node depends on apps/linux_uconsole_gtk.</p>
<dl>
<div><dt>Responsibility</dt><dd>apps/nrf52_node depends on apps/linux_uconsole_gtk.</dd></div>
<div><dt>Boundary</dt><dd>apps/linux_uconsole_gtk does not belong to the internal boundaries of apps/nrf52_node; it is only a dependent adjacent module in the current graph.</dd></div>
<div><dt>Relationship meaning</dt><dd>apps/nrf52_node -> apps/linux_uconsole_gtk indicates that there are cross-border calls, references or configuration dependencies in the local warehouse evidence; it illustrates the direction of technical collaboration, but cannot independently prove the business process relationship.</dd></div>
<div><dt>Why it belongs to this layer</dt><dd>apps/linux_uconsole_gtk is projected as an adjacent Container candidate by path ownership, rather than apps/nrf52_node internal Component.</dd></div>
<div><dt>Drill-down intention</dt><dd>Enter the independent Container document of apps/linux_uconsole_gtk to view its own responsibilities and evidence; if there is no independent document, it will only be regarded as an external dependency fact.</dd></div>
</dl>
</article>
<article class="layer-card" data-praxis-anchor="architecture:c4:container:apps-nrf52_node:dep:apps-linux_cardputer_zero" data-praxis-kind="architecture_c4_element" data-praxis-confidence="medium" data-praxis-drilldowns="[]">
<h3>apps/linux_cardputer_zero</h3>
<p>Container · medium</p>
<p>apps/nrf52_node depends on apps/linux_cardputer_zero.</p>
<dl>
<div><dt>Responsibility</dt><dd>apps/nrf52_node depends on apps/linux_cardputer_zero.</dd></div>
<div><dt>Boundary</dt><dd>apps/linux_cardputer_zero does not belong to the internal boundaries of apps/nrf52_node; it is just a dependent adjacent module in the current graph.</dd></div>
<div><dt>Relationship meaning</dt><dd>apps/nrf52_node -> apps/linux_cardputer_zero indicates that there are cross-border calls, references or configuration dependencies in the local warehouse evidence; it illustrates the direction of technical collaboration, but cannot independently prove the business process relationship.</dd></div>
<div><dt>Why it belongs to this layer</dt><dd>apps/linux_cardputer_zero is projected as an adjacent Container candidate by path ownership, rather than apps/nrf52_node internal Component.</dd></div>
<div><dt>Drill-down intention</dt><dd>Enter the independent Container document of apps/linux_cardputer_zero to view its own responsibilities and evidence; if there is no independent document, it will only be regarded as an external dependency fact.</dd></div>
</dl>
</article>
</div>
</section>
<section class="semantic-layer architecture-c4-links" data-praxis-anchor="architecture:c4:drilldowns" data-praxis-kind="architecture_c4_links">
<h2>Can drill down to C4</h2>
<div class="layer-grid">
<article class="layer-card document-entry-card" role="link" tabindex="0" data-praxis-anchor="architecture:c4:component:apps-nrf52_node" data-praxis-kind="architecture_c4_link" data-praxis-document-title="Component responsibility: apps/nrf52_node" data-praxis-document-summary="Enter Component responsibility: apps/nrf52_node You can answer "Container boundary: which internal components are hosted by apps/nrf52_node". Focus on portals, orchestration, adaptation, contracts, and shared objects rather than browsing the entire file." data-praxis-document-md="docs/architecture/c4/components/apps-nrf52_node/component.md" data-praxis-document-html="docs/architecture/c4/components/apps-nrf52_node/component.html">
<strong>Component responsibility: apps/nrf52_node</strong>
<span>contains</span>
<p>Enter Component responsibility: apps/nrf52_node can answer "Container boundary: which internal components are hosted by apps/nrf52_node". Focus on portals, orchestration, adaptation, contracts, and shared objects rather than browsing the entire file.</p>
<small>Explain the key responsibility units inside apps/nrf52_node from the C4 Component layer: entry, page, command, interface, registry, adapter or shared object.</small>
</article>
<article class="layer-card document-entry-card" role="link" tabindex="0" data-praxis-anchor="architecture:c4:code:apps-nrf52_node" data-praxis-kind="architecture_c4_link" data-praxis-document-title="Code anchor point: apps/nrf52_node" data-praxis-document-summary="Enter the code anchor point: apps/nrf52_node to trace the architectural responsibilities of the container boundary: apps/nrf52_node to the specific file/symbol anchor point; only when you need to determine the implementation entry or the impact of the change, you should drill down to Code." data-praxis-document-md="docs/architecture/c4/code/apps-nrf52_node/code.md" data-praxis-document-html="docs/architecture/c4/code/apps-nrf52_node/code.html">
<strong>Code anchor point: apps/nrf52_node</strong>
<span>details</span>
<p>Enter code anchor point: apps/nrf52_node to trace the architectural responsibility of container boundary: apps/nrf52_node to the specific file/symbol anchor point; only when you need to determine the implementation entry or the impact of the change, you should drill down to Code.</p>
<small>Explain a few key code anchors in apps/nrf52_node from the C4 Code layer. The Code layer is not a code browser and is only used when you need to understand how architectural components fall into specific files/symbols.</small>
</article>
</div>
</section>
<section class="semantic-layer architecture-c4-links" data-praxis-anchor="architecture:c4:engineering-links" data-praxis-kind="architecture_c4_links">
<h2>Associated software structure model</h2>
<div class="layer-grid">
<article class="layer-card document-entry-card" role="link" tabindex="0" data-praxis-anchor="architecture:c4:engineering-link:docs-engineering-package-diagrams-apps-nrf52_node-package-diagram" data-praxis-kind="architecture_c4_link" data-praxis-document-title="apps/nrf52_node Package Diagram" data-praxis-document-summary="View the boundaries, dependencies and complexity candidates of the software structure package/module to which the Container belongs." data-praxis-document-md="docs/engineering/package-diagrams/apps-nrf52_node/package-diagram.md" data-praxis-document-html="docs/engineering/package-diagrams/apps-nrf52_node/package-diagram.html">
<strong>apps/nrf52_node Package Diagram</strong>
<span>related_engineering</span>
<p>View the boundaries, dependencies and complexity candidates of the software structure package/module to which the Container belongs.</p>
<small>View the boundaries, dependencies and complexity candidates of the software structure package/module to which the Container belongs.</small>
</article>
</div>
</section>
<section class="semantic-layer" data-praxis-anchor="architecture:c4:evidence" data-praxis-kind="architecture_c4_list">
<h2>Evidence</h2>
<ul>
<li>apps/nrf52_node/APP_SHELL_MANIFEST.md</li>
<li>apps/nrf52_node/library.json</li>
<li>apps/nrf52_node/README.md</li>
<li>apps/nrf52_node/src/nrf52_node_app_facade_runtime.cpp</li>
<li>apps/nrf52_node/src/nrf52_node_app_facade_runtime.h</li>
<li>apps/nrf52_node/src/nrf52_node_app_runtime_access.cpp</li>
<li>apps/nrf52_node/src/nrf52_node_app_runtime_access.h</li>
<li>apps/nrf52_node/src/nrf52_node_app_shell.cpp</li>
</ul>
</section>
<section class="semantic-layer" data-praxis-anchor="architecture:c4:questions" data-praxis-kind="architecture_c4_list">
<h2>Judgment basis</h2>
<ul>
<li>The boundary must be supported by the running entrance, build/deployment configuration, service interface, application entrance, data storage or independent execution evidence; directory name, number of files or number of dependencies alone are not enough to establish.</li>
<li>I</li>
</ul>
</section>
<script type="application/json" id="praxis-architecture-c4-document">{"id":"architecture:c4:container:apps-nrf52_node","level":"container","title":"Container boundary: apps/nrf52_node","summary":"apps/nrf52_node is a C4 Container layer candidate boundary: it must appear as an application, service, data store, runnable unit, or independently deployable/executable system part, rather than a normal directory, code layering, or shared collection of tools.","docPath":"docs/architecture/c4/containers/apps-nrf52_node/container.md","htmlPath":"docs/architecture/c4/containers/apps-nrf52_node/container.html","anchor":"architecture:c4:container:apps-nrf52_node","status":"candidate","confidence":"high","mermaid":"flowchart LR\n container[\"apps/nrf52_node\"]\n dependency_1[\"apps/esp32_lvgl\"]\n container --> dependency_1\n dependency_2[\"apps/linux_uconsole_gtk\"]\n container --> dependency_2\n dependency_3[\"apps/linux_cardputer_zero\"]\n container --> dependency_3","responsibility":"apps/nrf52_node is an application-level Container candidate: warehouse evidence shows it is close to a runnable entry, a desktop/front-end/back-end application shell, or a user-perceivable system capability.","boundary":"The boundary comes from the warehouse path apps/nrf52_node. C4 Container is not equal to any package or code layer; only boundaries with applications, services, data storage, runtime portals, deployment units, external interfaces or independent execution semantics enter this layer. Ordinary configuration files, document directories, CI directories, warehouse management files and pure code layering can only be used as evidence or software structure model objects, not as Containers.","relationships":["Depends on other Containers: apps/esp32_lvgl, apps/linux_uconsole_gtk, apps/linux_cardputer_zero.","Contains 14 candidate component view objects, 0 run/collaboration links, and 0 run or build nodes."],"businessRelation":["This Container is not the business use case itself; it only explains the internal application/service/data storage/operation unit of the software system through which the business capability enters or passes.","If the Use Case in the organization/process model refers to this boundary, how it enters this Container should be explained in the Use Case drill-down document instead of writing the business process into the C4 Container diagram."],"engineeringRelation":["Corresponds to the software structure model Package Diagram: docs/engineering/package-diagrams/apps-nrf52_node/package-diagram.html.","Continue to enter the software structure model to view drill-down UML, structural collaboration, running links and complexity candidate points."],"evidencePaths":["apps/nrf52_node/APP_SHELL_MANIFEST.md","apps/nrf52_node/library.json","apps/nrf52_node/README.md","apps/nrf52_node/src/nrf52_node_app_facade_runtime.cpp","apps/nrf52_node/src/nrf52_node_app_facade_runtime.h","apps/nrf52_node/src/nrf52_node_app_runtime_access.cpp","apps/nrf52_node/src/nrf52_node_app_runtime_access.h","apps/nrf52_node/src/nrf52_node_app_shell.cpp"],"questions":["The boundary must be supported by the running entrance, build/deployment configuration, service interface, application entrance, data storage or independent execution evidence; directory name, number of files or number of dependencies alone are not enough to establish.","In the absence of evidence of operation, deployment, interfaces, or data storage, the build process reduces confidence or does not build standalone Containers."],"scope":{"packageId":"apps/nrf52_node","filePath":"apps/nrf52_node"},"elements":[{"id":"architecture:c4:container:apps-nrf52_node:self","label":"apps/nrf52_node","level":"container","anchor":"architecture:c4:container:apps-nrf52_node:self","summary":"This node in the diagram represents apps/nrf52_node, the C4 Container; the current document records 14 component drill-down entries, 0 running collaboration threads and 0 running or build nodes.","responsibility":"apps/nrf52_node is an application-level Container candidate: warehouse evidence shows it is close to a runnable entry, a desktop/front-end/back-end application shell, or a user-perceivable system capability.","boundary":"The boundary comes from the warehouse path apps/nrf52_node; the entry, service interface, application code, running configuration and deployment evidence under this path jointly support it to enter the Container layer. Ordinary configuration files, document directories or pure code layers will not form a Container alone.","relationshipMeaning":"The figure points from apps/nrf52_node to the external boundary, indicating that this runnable boundary will call, reference or depend on other Containers; these relationships are used to determine deployment, interfaces and change impacts.","whyThisLevel":"The node enters the Container layer because the local warehouse evidence shows that it has applications, services, data storage, running portals, deployment units, external interfaces, or independent execution semantics; not because it is just a directory or package.","drilldownIntent":"Drill down from apps/nrf52_node to Component to view the decomposition of responsibilities within the boundary.","evidence":["apps/nrf52_node/APP_SHELL_MANIFEST.md","apps/nrf52_node/library.json","apps/nrf52_node/README.md","apps/nrf52_node/src/nrf52_node_app_facade_runtime.cpp","apps/nrf52_node/src/nrf52_node_app_facade_runtime.h","apps/nrf52_node/src/nrf52_node_app_runtime_access.cpp","apps/nrf52_node/src/nrf52_node_app_runtime_access.h","apps/nrf52_node/src/nrf52_node_app_shell.cpp"],"confidence":"high","drilldowns":[{"id":"architecture:c4:component:apps-nrf52_node","level":"component","title":"Component responsibility: apps/nrf52_node","summary":"Explain the key responsibility units inside apps/nrf52_node from the C4 Component layer: entry, page, command, interface, registry, adapter or shared object.","docPath":"docs/architecture/c4/components/apps-nrf52_node/component.md","htmlPath":"docs/architecture/c4/components/apps-nrf52_node/component.html","anchor":"architecture:c4:component:apps-nrf52_node","relation":"contains","reason":"Enter Component responsibility: apps/nrf52_node can answer \"Container boundary: which internal components are hosted by apps/nrf52_node\". Focus on portals, orchestration, adaptation, contracts, and shared objects rather than browsing the entire file."},{"id":"architecture:c4:code:apps-nrf52_node","level":"code","title":"Code anchor point: apps/nrf52_node","summary":"Explain a few key code anchors in apps/nrf52_node from the C4 Code layer. The Code layer is not a code browser and is only used when you need to understand how architectural components fall into specific files/symbols.","docPath":"docs/architecture/c4/code/apps-nrf52_node/code.md","htmlPath":"docs/architecture/c4/code/apps-nrf52_node/code.html","anchor":"architecture:c4:code:apps-nrf52_node","relation":"details","reason":"Enter code anchor point: apps/nrf52_node to trace the architectural responsibility of container boundary: apps/nrf52_node to the specific file/symbol anchor point; only when you need to determine the implementation entry or the impact of the change, you should drill down to Code."}]},{"id":"architecture:c4:container:apps-nrf52_node:dep:apps-esp32_lvgl","label":"apps/esp32_lvgl","level":"container","anchor":"architecture:c4:container:apps-nrf52_node:dep:apps-esp32_lvgl","summary":"apps/nrf52_node depends on apps/esp32_lvgl.","responsibility":"apps/nrf52_node depends on apps/esp32_lvgl.","boundary":"apps/esp32_lvgl does not belong to the internal boundaries of apps/nrf52_node; it is only a dependent adjacent module in the current graph.","relationshipMeaning":"apps/nrf52_node -> apps/esp32_lvgl indicates that there are cross-border calls, references or configuration dependencies in the local warehouse evidence; it illustrates the direction of technical collaboration, but cannot independently prove the business process relationship.","whyThisLevel":"apps/esp32_lvgl is projected as an adjacent Container candidate by path ownership, rather than apps/nrf52_node internal Component.","drilldownIntent":"Enter the independent Container document of apps/esp32_lvgl to view its own responsibilities and evidence; if there is no independent document, it will only be regarded as an external dependency fact.","evidence":["dependency edge: apps/nrf52_node -> apps/esp32_lvgl"],"confidence":"medium","drilldowns":[]},{"id":"architecture:c4:container:apps-nrf52_node:dep:apps-linux_uconsole_gtk","label":"apps/linux_uconsole_gtk","level":"container","anchor":"architecture:c4:container:apps-nrf52_node:dep:apps-linux_uconsole_gtk","summary":"apps/nrf52_node depends on apps/linux_uconsole_gtk.","responsibility":"apps/nrf52_node depends on apps/linux_uconsole_gtk.","boundary":"apps/linux_uconsole_gtk does not belong to the internal boundaries of apps/nrf52_node; it is only a dependent adjacent module in the current graph.","relationshipMeaning":"apps/nrf52_node -> apps/linux_uconsole_gtk indicates that there are cross-border calls, references or configuration dependencies in the local warehouse evidence; it illustrates the direction of technical collaboration, but cannot independently prove the business process relationship.","whyThisLevel":"apps/linux_uconsole_gtk is projected as an adjacent Container candidate by path ownership, rather than apps/nrf52_node internal Component.","drilldownIntent":"Enter the independent Container document of apps/linux_uconsole_gtk to view its own responsibilities and evidence; if there is no independent document, it will only be regarded as an external dependency fact.","evidence":["dependency edge: apps/nrf52_node -> apps/linux_uconsole_gtk"],"confidence":"medium","drilldowns":[]},{"id":"architecture:c4:container:apps-nrf52_node:dep:apps-linux_cardputer_zero","label":"apps/linux_cardputer_zero","level":"container","anchor":"architecture:c4:container:apps-nrf52_node:dep:apps-linux_cardputer_zero","summary":"apps/nrf52_node depends on apps/linux_cardputer_zero.","responsibility":"apps/nrf52_node depends on apps/linux_cardputer_zero.","boundary":"apps/linux_cardputer_zero does not belong to the internal boundaries of apps/nrf52_node; it is just a dependent adjacent module in the current graph.","relationshipMeaning":"apps/nrf52_node -> apps/linux_cardputer_zero indicates that there are cross-border calls, references or configuration dependencies in the local warehouse evidence; it illustrates the direction of technical collaboration, but cannot independently prove the business process relationship.","whyThisLevel":"apps/linux_cardputer_zero is projected as an adjacent Container candidate by path ownership, rather than apps/nrf52_node internal Component.","drilldownIntent":"Enter the independent Container document of apps/linux_cardputer_zero to view its own responsibilities and evidence; if there is no independent document, it will only be regarded as an external dependency fact.","evidence":["dependency edge: apps/nrf52_node -> apps/linux_cardputer_zero"],"confidence":"medium","drilldowns":[]}],"drilldowns":[{"id":"architecture:c4:component:apps-nrf52_node","level":"component","title":"Component responsibility: apps/nrf52_node","summary":"Explain the key responsibility units inside apps/nrf52_node from the C4 Component layer: entry, page, command, interface, registry, adapter or shared object.","docPath":"docs/architecture/c4/components/apps-nrf52_node/component.md","htmlPath":"docs/architecture/c4/components/apps-nrf52_node/component.html","anchor":"architecture:c4:component:apps-nrf52_node","relation":"contains","reason":"Enter Component responsibility: apps/nrf52_node can answer \"Container boundary: which internal components are hosted by apps/nrf52_node\". Focus on portals, orchestration, adaptation, contracts, and shared objects rather than browsing the entire file."},{"id":"architecture:c4:code:apps-nrf52_node","level":"code","title":"Code anchor point: apps/nrf52_node","summary":"Explain a few key code anchors in apps/nrf52_node from the C4 Code layer. The Code layer is not a code browser and is only used when you need to understand how architectural components fall into specific files/symbols.","docPath":"docs/architecture/c4/code/apps-nrf52_node/code.md","htmlPath":"docs/architecture/c4/code/apps-nrf52_node/code.html","anchor":"architecture:c4:code:apps-nrf52_node","relation":"details","reason":"Enter code anchor point: apps/nrf52_node to trace the architectural responsibility of container boundary: apps/nrf52_node to the specific file/symbol anchor point; only when you need to determine the implementation entry or the impact of the change, you should drill down to Code."}],"relatedEngineeringDocs":[{"id":"architecture:c4:engineering-link:docs-engineering-package-diagrams-apps-nrf52_node-package-diagram","level":"code","title":"apps/nrf52_node Package Diagram","summary":"View the boundaries, dependencies and complexity candidates of the software structure package/module to which the Container belongs.","docPath":"docs/engineering/package-diagrams/apps-nrf52_node/package-diagram.md","htmlPath":"docs/engineering/package-diagrams/apps-nrf52_node/package-diagram.html","anchor":"architecture:c4:engineering-link:docs-engineering-package-diagrams-apps-nrf52_node-package-diagram","relation":"related_engineering","reason":"View the boundaries, dependencies and complexity candidates of the software structure package/module to which the Container belongs."}]}</script>
</main>
</body>
</html>