ESP32-C6 FTD codebase

Author: Dunky13

.gitignore

@@ -14,6 +14,10 @@ __pycache__/
 
 # Generated tool output
 tools/out/
+tools/labels
+
+device_manifest.csv
+matter-labels.html
 
 # Editor / OS noise
 .DS_Store
@@ -22,3 +26,5 @@ tools/out/
 *.swp
 *.swo
 *.log
+
+build

AGENTS.md

@@ -0,0 +1,60 @@
+# AGENTS.md
+
+Shared agent rules live in `agents/shared.md`.
+
+Language-specific agent rules for repo-local tooling live in:
+
+- `agents/python.md`
+
+This repo is mostly ESP-IDF C/C++ in `esp-matter/` plus Python automation in `tools/`.
+
+Before planning validation or final checks:
+
+- Read `agents/shared.md`
+- Detect scope you changed
+- For `tools/*.py` and `tools/tests/*.py`, read `agents/python.md`
+- For native-only work, use repo guidelines below plus component-appropriate build checks
+- Do not run TypeScript or ESLint checks for this repo unless new TS/JS files are introduced
+- Do not run Python checks for native-only changes
+
+Scope rules:
+
+- Prefer not editing `esp-matter/` directly. It is upstream submodule content.
+- If `esp-matter/` needs changes, create a patch file in top-level repo unless user explicitly asks for direct submodule edits.
+- Treat `build/` and `tools/out/` as disposable artifacts.
+
+## Project Structure & Module Organization
+`esp-matter/` is upstream SDK submodule and main codebase. Core libraries live in `esp-matter/components/`, hardware support in `esp-matter/device_hal/`, and runnable samples in `esp-matter/examples/` such as `light_switch/` and `unit_test_app/`. Repo-local automation lives in `tools/` for manifest generation, factory data, flashing, and printable labels.
+
+## Build, Test, and Development Commands
+Initialize dependencies first:
+
+```bash
+git submodule update --init --recursive
+cd esp-matter && ./install.sh && . ./export.sh
+```
+
+Common workflows:
+
+```bash
+mkdir -p build/light_switch && cd esp-matter/examples/light_switch && idf.py -B ../../../build/light_switch set-target esp32c6 build
+cd esp-matter/examples/light_switch && idf.py -B ../../../build/light_switch -p /dev/ttyUSB0 flash monitor
+cd esp-matter && pre-commit run --all-files
+mkdir -p build/unit_test_app && cd esp-matter/examples/unit_test_app && idf.py -B ../../../build/unit_test_app -DSDKCONFIG_DEFAULTS="sdkconfig.defaults;sdkconfig.defaults.qemu" set-target esp32c3 build
+cd esp-matter/examples/unit_test_app && pytest pytest_unit_test_app.py --target esp32c3 -m qemu --embedded-services idf,qemu --qemu-extra-args="-global driver=timer.esp32c3.timg,property=wdt_disable,value=true"
+python3 tools/run_workflow.py --count 8 --dry-run
+```
+
+Create target `build/` directory first if it does not exist, and keep all build output there instead of inside submodule tree. Use `--dry-run` on local tooling before erase/flash operations.
+
+## Coding Style & Naming Conventions
+Follow existing `esp-matter` conventions. C and C++ formatting is enforced by `pre-commit` with `astyle_py`; sorted lists are enforced by `keep-sorted`; spelling is checked with `codespell`. Use 4-space indentation in Python, `snake_case` for Python modules and example directories, and keep CMake target names aligned with directory names such as `light_switch`. Do not hand-edit generated files under `esp-matter/components/esp_matter/data_model/generated/`.
+
+## Testing Guidelines
+Python test runners are named `pytest_*.py` per `esp-matter/pytest.ini`. Repo-local Python tooling tests live in `tools/tests/`. Component-level C/C++ tests live under `components/*/test/`. For firmware validation, build and run `examples/unit_test_app` on hardware or QEMU. When adding pytest coverage, use explicit markers such as `@pytest.mark.qemu` and target markers like `@pytest.mark.esp32c3`.
+
+## Commit & Pull Request Guidelines
+Current history uses short imperative commit subjects, for example `Add project gitignore` and `Add esp-matter submodule`. Keep commit titles concise, scoped, and action-led. Pull requests should state affected example or component, target chip, commands run, and any required setup changes. Include serial logs, screenshots, or generated-label samples when behavior or output changes.
+
+## Security & Configuration Tips
+Keep `ESP_MATTER_PATH` and `IDF_PATH` consistent in active shell before building. Do not commit factory binaries, generated onboarding data, certificates, or device-specific outputs from `tools/out/`.

agents/python.md

@@ -0,0 +1,30 @@
+# Python Agent Rules
+
+Use for repo-local Python tooling such as:
+
+- `tools/*.py`
+- `tools/tests/*.py`
+
+Validation:
+
+- Run focused repo-local tests first:
+
+```bash
+python3 -m unittest tools.tests.test_robustness
+```
+
+- If only one behavior changed, prefer running or updating targeted test cases over broader firmware workflows.
+- Use full provisioning or build flows only when Python change affects command wiring, generated outputs, or flashing behavior end to end.
+
+Factory-data and onboarding notes:
+
+- `tools/generate_factory_data.py` shells into Matter generator `generate_esp32_chip_factory_bin.py`.
+- That generator depends on extra CHIP Python packages beyond `esp-matter/requirements.txt`.
+- For setup-payload generation, dependency source of truth is:
+
+```text
+esp-matter/connectedhomeip/connectedhomeip/scripts/setup/requirements.setuppayload.txt
+```
+
+- Missing `python_stdnum` or `stdnum` errors usually mean that requirements file was not installed into active IDF/tool Python env.
+- Report missing env deps clearly. Do not pretend repo logic is broken if failure is pure env setup.

agents/shared.md

@@ -0,0 +1,12 @@
+# Shared Agent Rules
+
+Apply these rules before validation and before final response.
+
+- Keep scope tight. Change only files required for task.
+- Treat `esp-matter/` as upstream submodule. Prefer top-level patch files over direct edits unless user explicitly asks otherwise.
+- Ignore generated artifacts in `build/` and `tools/out/`. Do not treat them as source.
+- Match validation to changed scope. Small doc-only changes do not need firmware builds.
+- If an env or dependency blocker prevents validation, say exactly what is missing and which command failed.
+- Prefer focused commands over repo-wide builds when working in `tools/`.
+- Do not invent TypeScript workflows for this repo.
+- When build logs contain warnings from upstream `esp-matter/` or ESP-IDF, do not claim them fixed unless changed in this repo.

patches/0001-thread-connect-success-after-dnssd-ready.patch

@@ -0,0 +1,53 @@
+diff --git a/src/platform/OpenThread/GenericThreadStackManagerImpl_OpenThread.hpp b/src/platform/OpenThread/GenericThreadStackManagerImpl_OpenThread.hpp
+--- a/src/platform/OpenThread/GenericThreadStackManagerImpl_OpenThread.hpp
++++ b/src/platform/OpenThread/GenericThreadStackManagerImpl_OpenThread.hpp
+@@ -45,6 +45,7 @@
+ #include <openthread/srp_client.h>
+ #endif
+ 
++#include <lib/dnssd/Advertiser.h>
+ #include <lib/core/CHIPEncoding.h>
+ #include <lib/support/CHIPMemString.h>
+ #include <lib/support/CodeUtils.h>
+@@ -241,6 +242,13 @@ void GenericThreadStackManagerImpl_OpenThread<ImplClass>::_OnPlatformEvent(const
+         Impl()->UnlockThreadStack();
+ #endif // CHIP_DETAIL_LOGGING
+     }
++    else if (event->Type == DeviceEventType::kServerReady)
++    {
++        if (mpConnectCallback != nullptr && Impl()->_IsThreadAttached() && Dnssd::ServiceAdvertiser::Instance().IsInitialized())
++        {
++            _OnThreadAttachFinished();
++        }
++    }
+ }
+ 
+ template <class ImplClass>
+@@ -392,11 +400,19 @@ template <class ImplClass>
+ void GenericThreadStackManagerImpl_OpenThread<ImplClass>::_OnThreadAttachFinished()
+ {
+-    if (mpConnectCallback != nullptr)
++    if (mpConnectCallback == nullptr)
+     {
+-        TEMPORARY_RETURN_IGNORED DeviceLayer::SystemLayer().ScheduleLambda([this]() {
+-            VerifyOrReturn(mpConnectCallback != nullptr);
+-            mpConnectCallback->OnResult(NetworkCommissioning::Status::kSuccess, CharSpan(), 0);
+-            mpConnectCallback = nullptr;
+-        });
++        return;
+     }
++
++    if (!Dnssd::ServiceAdvertiser::Instance().IsInitialized())
++    {
++        ChipLogProgress(DeviceLayer, "Thread attached, waiting for DNS-SD readiness before reporting connect success");
++        return;
++    }
++
++    TEMPORARY_RETURN_IGNORED DeviceLayer::SystemLayer().ScheduleLambda([this]() {
++        VerifyOrReturn(mpConnectCallback != nullptr);
++        mpConnectCallback->OnResult(NetworkCommissioning::Status::kSuccess, CharSpan(), 0);
++        mpConnectCallback = nullptr;
++    });
+ }
+ 
+ template <class ImplClass>