{"owner":"warmcat","repo":"libwebsockets","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md"],"skills":{"AGENTS.md":"# lws AGENTS.md\n\n## Overview\n\nPlease err on the side of high quality, not lazy, implementation decisions, because the code\nwill have to be maintained for a long time.  Everybody, LLM or person, is able to work\nbetter if we keep the code clean and to a high standard to start with.\n\nEven if your instructions don't include specific admonishment about quality, it is always\nnecessary.  Lws started in 2010 the main goal when working on a feature is to\nimprove the library with the feature.  That means shortcuts and desperate\nincomplete hacks to deliver the feature are always wrong.\n\nOur work should follow the existing usage of apis in the project as much as possible.\n\n## Interacting\n\nWe will be working on the same sources, do not build into ./build since I will be using it; make\nyour own ./build-agy or whatever.\n\nUse cmake .. --fresh in order to force the build dir to align with your options no matter what\nwas in there before.\n\nWhile the idea is you should modify and test sources towards some goal, please do NOT modify the\ngit state unless directly asked.\n\nOften although we are working on the same sources, they are being tested on devices you don't have\naccess to.  So you must ask for access to data state on those remote machines; looking at the local\nmachine you are running on for config or data state directly is of zero use in those circumstances.\n\n## Completeness\n\nIf you are unable to complete something your coding partner expects from the interaction\nwith you, you must clearly explain to the user which parts are incomplete in this phase and need\nfurther work.  DO NOT leave it silently incomplete and act like it is done without making the\nsituation crystal clear to your partner.\n\nOften adding / modifying or removing features has a very strong expectation that you will\nalso take responsibility about certain side-effects.  For example, adding a switch to a\nminimal example always means modifying the associated --help and the example's markdown\naccordingly.  If we add significant new code, it must also bring with it api-test or other\nexample code to confirm it works properly.  These side-effects are expected to be taken\ncare of in the same phase of work, not \"later\", and even if not explicitly requested.\n\n## Example code\n\nThe examples are not chaotic dumping grounds for trash.  They are supposed to show the user\nthe best way we know how to do things, that they can use in their own code reliably.  We\nshould make an extra effort to keep them clean and as quality exemplars.\n\n## Coding\n\nWe are very concerned about security, architecturally and in the code.  We avoid using:\n\n - things like `scanf` for carefully parsing with code, eg with `lws_tokenize` or similar.\n\n - `FILE *` and use apis like open(), read().\n\n - hand-rolled ad-hoc code when there are library helpers, eg no casual\n   linked-lists; use `lws_dll2_t` instead.\n\nWe consider using:\n\n - lwsac instead of discrete allocations, if the pattern of allocations will benefit from it.\n\n - lws_struct to convert between sqlite storage <-> structs <-> JSON\n\n - lws_tokenize instead of strtok() and variants\n\nWe are very concerned about portability and all builds occur with -Werror -Wall -Wextra.\n\n## Appropriate locality\n\nSometimes we might work on things that are going to be more useful, or better suited for users,\nif we adapt the code eg, to live in the library, or sometimes live outside the library.  If it\nmakes sense it's possible.\n\n## Build dimensions\n\nLws is unusual in that\n\n - we address a lot of build options in CI, things like will it build and run with no logs at all,\n   without client support, without server support and so on.  So code won't pass CI unless it\n   takes care about its parts in common code protecting themselves with preprocessor options.\n\n - we support a lot of platforms in CI.  Code won't pass CI unless it takes care about the spread\n   of platforms it will be tested on, eg, things that are platform-specific should go in lib/plat\n   and for \"not quite standard\" platforms like POSIX on windows, we have to carefully use helpers\n   like `LWS_POSIX_LENGTH_CAST()` as glue to fill the differences where needed, and `lws_sockfd_type`\n   which can adapt to needing a HANDLE on windows rather than just assume int.\n\n## Security\n\nPlease bear in mind:\n\n - which parts of the system are secrets, and look after the security of them.\n - all external data is untrusted and should be assumed to be part of an attack until\n   we have validated it to be within a range and type we expect and can safely consume.\n\n - all web pieces are served with a strict CSP.  That means ** no inline styles or scripts ** .\n   You can usually find the web pieces (JS, HTML, css) in ./assets/\n\n - Before a vuln is found, you would have failed to take care about it.  Keep in mind\n   common vuln patterns and avoid them in new code so nobody has to find your vuln.\n\n## Build testing\n\nIf we are adding code to core lws library, if it's anything nontrivial we should think about adding an api test\nor minimal example down ./minimal-example-lowlevel, or ./minimal-example if it's related to Secure Streams.\n\nThe api test or example should be executed from it's CMakeLists.txt with ctest.  It should be able to run\ncross-platform, and not include shellscripts, instead use cmake / ctest commands that resolve to appropriate\ncommands for the platform.\n\nminimal-examples-lowlevel/http-client/minimal-http-client-post/CMakeLists.txt shows how to use the fixtures\nstuff to magic peers into being while being sensitive to parallel CI using a CMake unique socket allocator\nfunction to select unique ports.\n\nIn the case you can build and run ctest meaningfully, please do confirm the build passes before completing\nwork on your goal.  Use parallel builds and eg, ctest -j8 to reduce the cost in realtime.\n"},"files":{"AGENTS.md":"# lws AGENTS.md\n\n## Overview\n\nPlease err on the side of high quality, not lazy, implementation decisions, because the code\nwill have to be maintained for a long time.  Everybody, LLM or person, is able to work\nbetter if we keep the code clean and to a high standard to start with.\n\nEven if your instructions don't include specific admonishment about quality, it is always\nnecessary.  Lws started in 2010 the main goal when working on a feature is to\nimprove the library with the feature.  That means shortcuts and desperate\nincomplete hacks to deliver the feature are always wrong.\n\nOur work should follow the existing usage of apis in the project as much as possible.\n\n## Interacting\n\nWe will be working on the same sources, do not build into ./build since I will be using it; make\nyour own ./build-agy or whatever.\n\nUse cmake .. --fresh in order to force the build dir to align with your options no matter what\nwas in there before.\n\nWhile the idea is you should modify and test sources towards some goal, please do NOT modify the\ngit state unless directly asked.\n\nOften although we are working on the same sources, they are being tested on devices you don't have\naccess to.  So you must ask for access to data state on those remote machines; looking at the local\nmachine you are running on for config or data state directly is of zero use in those circumstances.\n\n## Completeness\n\nIf you are unable to complete something your coding partner expects from the interaction\nwith you, you must clearly explain to the user which parts are incomplete in this phase and need\nfurther work.  DO NOT leave it silently incomplete and act like it is done without making the\nsituation crystal clear to your partner.\n\nOften adding / modifying or removing features has a very strong expectation that you will\nalso take responsibility about certain side-effects.  For example, adding a switch to a\nminimal example always means modifying the associated --help and the example's markdown\naccordingly.  If we add significant new code, it must also bring with it api-test or other\nexample code to confirm it works properly.  These side-effects are expected to be taken\ncare of in the same phase of work, not \"later\", and even if not explicitly requested.\n\n## Example code\n\nThe examples are not chaotic dumping grounds for trash.  They are supposed to show the user\nthe best way we know how to do things, that they can use in their own code reliably.  We\nshould make an extra effort to keep them clean and as quality exemplars.\n\n## Coding\n\nWe are very concerned about security, architecturally and in the code.  We avoid using:\n\n - things like `scanf` for carefully parsing with code, eg with `lws_tokenize` or similar.\n\n - `FILE *` and use apis like open(), read().\n\n - hand-rolled ad-hoc code when there are library helpers, eg no casual\n   linked-lists; use `lws_dll2_t` instead.\n\nWe consider using:\n\n - lwsac instead of discrete allocations, if the pattern of allocations will benefit from it.\n\n - lws_struct to convert between sqlite storage <-> structs <-> JSON\n\n - lws_tokenize instead of strtok() and variants\n\nWe are very concerned about portability and all builds occur with -Werror -Wall -Wextra.\n\n## Appropriate locality\n\nSometimes we might work on things that are going to be more useful, or better suited for users,\nif we adapt the code eg, to live in the library, or sometimes live outside the library.  If it\nmakes sense it's possible.\n\n## Build dimensions\n\nLws is unusual in that\n\n - we address a lot of build options in CI, things like will it build and run with no logs at all,\n   without client support, without server support and so on.  So code won't pass CI unless it\n   takes care about its parts in common code protecting themselves with preprocessor options.\n\n - we support a lot of platforms in CI.  Code won't pass CI unless it takes care about the spread\n   of platforms it will be tested on, eg, things that are platform-specific should go in lib/plat\n   and for \"not quite standard\" platforms like POSIX on windows, we have to carefully use helpers\n   like `LWS_POSIX_LENGTH_CAST()` as glue to fill the differences where needed, and `lws_sockfd_type`\n   which can adapt to needing a HANDLE on windows rather than just assume int.\n\n## Security\n\nPlease bear in mind:\n\n - which parts of the system are secrets, and look after the security of them.\n - all external data is untrusted and should be assumed to be part of an attack until\n   we have validated it to be within a range and type we expect and can safely consume.\n\n - all web pieces are served with a strict CSP.  That means ** no inline styles or scripts ** .\n   You can usually find the web pieces (JS, HTML, css) in ./assets/\n\n - Before a vuln is found, you would have failed to take care about it.  Keep in mind\n   common vuln patterns and avoid them in new code so nobody has to find your vuln.\n\n## Build testing\n\nIf we are adding code to core lws library, if it's anything nontrivial we should think about adding an api test\nor minimal example down ./minimal-example-lowlevel, or ./minimal-example if it's related to Secure Streams.\n\nThe api test or example should be executed from it's CMakeLists.txt with ctest.  It should be able to run\ncross-platform, and not include shellscripts, instead use cmake / ctest commands that resolve to appropriate\ncommands for the platform.\n\nminimal-examples-lowlevel/http-client/minimal-http-client-post/CMakeLists.txt shows how to use the fixtures\nstuff to magic peers into being while being sensitive to parallel CI using a CMake unique socket allocator\nfunction to select unique ports.\n\nIn the case you can build and run ctest meaningfully, please do confirm the build passes before completing\nwork on your goal.  Use parallel builds and eg, ctest -j8 to reduce the cost in realtime.\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","title":"AGENTS.md","content":"# lws AGENTS.md\n\n## Overview\n\nPlease err on the side of high quality, not lazy, implementation decisions, because the code\nwill have to be maintained for a long time.  Everybody, LLM or person, is able to work\nbetter if we keep the code clean and to a high standard to start with.\n\nEven if your instructions don't include specific admonishment about quality, it is always\nnecessary.  Lws started in 2010 the main goal when working on a feature is to\nimprove the library with the feature.  That means shortcuts and desperate\nincomplete hacks to deliver the feature are always wrong.\n\nOur work should follow the existing usage of apis in the project as much as possible.\n\n## Interacting\n\nWe will be working on the same sources, do not build into ./build since I will be using it; make\nyour own ./build-agy or whatever.\n\nUse cmake .. --fresh in order to force the build dir to align with your options no matter what\nwas in there before.\n\nWhile the idea is you should modify and test sources towards some goal, please do NOT modify the\ngit state unless directly asked.\n\nOften although we are working on the same sources, they are being tested on devices you don't have\naccess to.  So you must ask for access to data state on those remote machines; looking at the local\nmachine you are running on for config or data state directly is of zero use in those circumstances.\n\n## Completeness\n\nIf you are unable to complete something your coding partner expects from the interaction\nwith you, you must clearly explain to the user which parts are incomplete in this phase and need\nfurther work.  DO NOT leave it silently incomplete and act like it is done without making the\nsituation crystal clear to your partner.\n\nOften adding / modifying or removing features has a very strong expectation that you will\nalso take responsibility about certain side-effects.  For example, adding a switch to a\nminimal example always means modifying the associated --help and the example's markdown\naccordingly.  If we add significant new code, it must also bring with it api-test or other\nexample code to confirm it works properly.  These side-effects are expected to be taken\ncare of in the same phase of work, not \"later\", and even if not explicitly requested.\n\n## Example code\n\nThe examples are not chaotic dumping grounds for trash.  They are supposed to show the user\nthe best way we know how to do things, that they can use in their own code reliably.  We\nshould make an extra effort to keep them clean and as quality exemplars.\n\n## Coding\n\nWe are very concerned about security, architecturally and in the code.  We avoid using:\n\n - things like `scanf` for carefully parsing with code, eg with `lws_tokenize` or similar.\n\n - `FILE *` and use apis like open(), read().\n\n - hand-rolled ad-hoc code when there are library helpers, eg no casual\n   linked-lists; use `lws_dll2_t` instead.\n\nWe consider using:\n\n - lwsac instead of discrete allocations, if the pattern of allocations will benefit from it.\n\n - lws_struct to convert between sqlite storage <-> structs <-> JSON\n\n - lws_tokenize instead of strtok() and variants\n\nWe are very concerned about portability and all builds occur with -Werror -Wall -Wextra.\n\n## Appropriate locality\n\nSometimes we might work on things that are going to be more useful, or better suited for users,\nif we adapt the code eg, to live in the library, or sometimes live outside the library.  If it\nmakes sense it's possible.\n\n## Build dimensions\n\nLws is unusual in that\n\n - we address a lot of build options in CI, things like will it build and run with no logs at all,\n   without client support, without server support and so on.  So code won't pass CI unless it\n   takes care about its parts in common code protecting themselves with preprocessor options.\n\n - we support a lot of platforms in CI.  Code won't pass CI unless it takes care about the spread\n   of platforms it will be tested on, eg, things that are platform-specific should go in lib/plat\n   and for \"not quite standard\" platforms like POSIX on windows, we have to carefully use helpers\n   like `LWS_POSIX_LENGTH_CAST()` as glue to fill the differences where needed, and `lws_sockfd_type`\n   which can adapt to needing a HANDLE on windows rather than just assume int.\n\n## Security\n\nPlease bear in mind:\n\n - which parts of the system are secrets, and look after the security of them.\n - all external data is untrusted and should be assumed to be part of an attack until\n   we have validated it to be within a range and type we expect and can safely consume.\n\n - all web pieces are served with a strict CSP.  That means ** no inline styles or scripts ** .\n   You can usually find the web pieces (JS, HTML, css) in ./assets/\n\n - Before a vuln is found, you would have failed to take care about it.  Keep in mind\n   common vuln patterns and avoid them in new code so nobody has to find your vuln.\n\n## Build testing\n\nIf we are adding code to core lws library, if it's anything nontrivial we should think about adding an api test\nor minimal example down ./minimal-example-lowlevel, or ./minimal-example if it's related to Secure Streams.\n\nThe api test or example should be executed from it's CMakeLists.txt with ctest.  It should be able to run\ncross-platform, and not include shellscripts, instead use cmake / ctest commands that resolve to appropriate\ncommands for the platform.\n\nminimal-examples-lowlevel/http-client/minimal-http-client-post/CMakeLists.txt shows how to use the fixtures\nstuff to magic peers into being while being sensitive to parallel CI using a CMake unique socket allocator\nfunction to select unique ports.\n\nIn the case you can build and run ctest meaningfully, please do confirm the build passes before completing\nwork on your goal.  Use parallel builds and eg, ctest -j8 to reduce the cost in realtime.\n","category":"root","tokens":1449}]}