Skip to content

Guided tour

FabrCore 2.0 · Release and package availability

These guides track the current 2.0 source. Stable 2.0.0 publication is pending; package commands show the release target. Until it is published, follow the source quick start or use a matching available prerelease set. Release migration · Runtime modes

MODULE 14 · LESSON 14.1

Review the complete application

Review the app by capability, ownership and evidence.

Lesson 84 of 86 · FabrCore 2.0

Overview

Operations Desk now has a host, agents, tools, clients, knowledge and operations paths. The architecture is easiest to maintain when every capability has a clear owner and its configuration/lifetime is visible. Completing a tour is useful only if you can reproduce the checkpoints.

Return to the original request

At the beginning the client sent text to an echo agent. Your chosen path may now resolve a model, call a tool, retrieve knowledge and deliver a result through a UI. Trace the same SR-1042 request across those additions. Name the owning principal and configuration source at each step instead of listing packages without explaining their jobs.

Review only capabilities you enabled

The tour offers branches: Android versus integrated Blazor, optional Microsoft services, SQL knowledge and cloud operations. A product does not need all of them. Mark each architectural component as implemented and verified, planned, or outside scope in the application's own record. This is a deployment/engineering record, not a lesson-completion score.

Review the application by boundary

  1. Return to the request diagram from module 1 and add only the services your application actually uses.
  2. Use the module navigation to revisit any unexplained boundary. Keep the Android remote-client and Blazor integrated-client variants distinct.
  3. Run the local baseline and the SQL, Microsoft or Cloud Server checks required by your enabled features, then record their results in your project.

Walk one request from input to result

  1. Run the echo baseline to confirm transport, then the actual enabled workflow with known fixture facts. Capture the final response and the supporting tool/knowledge result.
  2. For each hop, identify the runtime owner, configuration resource and retained data. Explain what happens if the connection drops or the process restarts at that point.
  3. List live integrations you did not exercise and remove claims that they are ready. Use the module navigation to revisit the corresponding implementation explanation when a boundary remains unclear.

The outcome is an explainable application with evidence for its enabled behavior. Finishing the reading does not replace those application-level checks.

If the result is different

Do not enable optional services solely to match the demo. A smaller app with verified boundaries is preferable to an unexplained configuration inventory.

Go deeper

Explore the related documentation.